Before I gut PDO_DBLIB one more time to implement native parameter
binding for stored procedures, what are the thoughts on returning the
column values from the database as the native PHP type when possible?
Currently everything is returned as a string, incurring overhead for
conversion and creating problems hinting at the desired binding type
for BLOBS and numeric data types.
Before I gut PDO_DBLIB one more time to implement native parameter
binding for stored procedures, what are the thoughts on returning the
column values from the database as the native PHP type when possible?
Currently everything is returned as a string, incurring overhead for
conversion
The design philosophy was to pull the data out as strings as this
gives the highest data fidelity (especially with the various numeric
types) and is a pragmatic choice for the majority of web apps which
are largely in text land anyway, and typically are not bottlenecked on
the performance of converting database column values.
Some drivers, particularly postgres, are unable to request string data
and therefore return their results in the type that most closely
matches the C datatype forced on it by the API.
This has been a source of complaints from some about the consistency
of the returned data for apps that are designed to run against
multiple database backends.
I would advise against changing the behavior of the driver if
possible, and against changing it away from the established
stringiness of PDO without good reason.
and creating problems hinting at the desired binding type
for BLOBS and numeric data types.
Can you elaborate on this? You can explicitly set the desired binding
via bindColumn.
--Wez.
Before I gut PDO_DBLIB one more time to implement native parameter
binding for stored procedures, what are the thoughts on returning the
column values from the database as the native PHP type when possible?
Currently everything is returned as a string, incurring overhead for
conversionThe design philosophy was to pull the data out as strings as this gives the
highest data fidelity (especially with the various numeric types) and is a
pragmatic choice for the majority of web apps which are largely in text land
anyway, and typically are not bottlenecked on the performance of converting
database column values.Some drivers, particularly postgres, are unable to request string data and
therefore return their results in the type that most closely matches the C
datatype forced on it by the API.This has been a source of complaints from some about the consistency of the
returned data for apps that are designed to run against multiple database
backends.I would advise against changing the behavior of the driver if possible, and
against changing it away from the established stringiness of PDO without
good reason.
One reason was to bring the driver in line with the behavior of the
PDO sqlserv driver (
http://msdn.microsoft.com/en-us/library/cc296193.aspx )
Eventually I would like yo make the 2 interchangeable and have PHP/PDO
applications run the same on Win32 and Linux.
and creating problems hinting at the desired binding type
for BLOBS and numeric data types.
Yes, you are right. I can bind columns as strings and parameters as a
specific data type independently.
Can you elaborate on this? You can explicitly set the desired binding via
bindColumn.--Wez.
Stanley Sufficool wrote:
One reason was to bring the driver in line with the behavior of the
PDO sqlserv driver (
http://msdn.microsoft.com/en-us/library/cc296193.aspx )Eventually I would like yo make the 2 interchangeable and have PHP/PDO
applications run the same on Win32 and Linux.
Two wrongs don't make it right?
Either we have PDO2 with a generic change on all drivers, or we get M$ to ollow
the standard and fix the sqlserv driver.
This STILL does not clear up some of the cross database problems but at least we
would all be working to the same set of rules?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Before I gut PDO_DBLIB one more time to implement native parameter
binding for stored procedures, what are the thoughts on returning the
column values from the database as the native PHP type when possible?
Currently everything is returned as a string, incurring overhead for
conversion and creating problems hinting at the desired binding type
for BLOBS and numeric data types.
It SEEMS like a Good Idea (tm) until you think it through and
realize that there is NOT a one-to-one correspondence between PHP
native types and DB native types.
Even what seems like a no-brainer for, say, INT is not. Does PHP INT
have the same range as the DB INT? Dollars to doughnuts says "No." is
the correct answer.
BIGINT? Not a chance. PHP doesn't really do bigint, unless you want
to return some GMP thing, which is probably not a Good Idea, as GMP
isn't always there, I don't think.
Then you start looking at things like an enum, or GeoIP, or IP address
as native DB types, and it gets really ugly, really fast.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Before I gut PDO_DBLIB one more time to implement native parameter
binding for stored procedures, what are the thoughts on returning the
column values from the database as the native PHP type when possible?
Currently everything is returned as a string, incurring overhead for
conversion and creating problems hinting at the desired binding type
for BLOBS and numeric data types.It SEEMS like a Good Idea (tm) until you think it through and
realize that there is NOT a one-to-one correspondence between PHP
native types and DB native types.Even what seems like a no-brainer for, say, INT is not. Does PHP INT
have the same range as the DB INT? Dollars to doughnuts says "No." is
the correct answer.BIGINT? Not a chance. PHP doesn't really do bigint, unless you want
to return some GMP thing, which is probably not a Good Idea, as GMP
isn't always there, I don't think.Then you start looking at things like an enum, or GeoIP, or IP address
as native DB types, and it gets really ugly, really fast.
I realize that non Zend types would have to be returned as a string
representation. The hangups I am having is with large objects returned
as streams in some drivers (but not dblib) and inconsistent date/time
string representations across drivers depending on server
configuration files (freetds.conf).
Another BIG issue I am having when using strings with DBLIB is that
they go through iconv, destroying binary values when translated to the
server character set from the assumed latin1 PHP client character set.
SQL Server for some reason allows characters to be stored in a
varchar/text fields even though the character is not defined in the
servers code page, whereas iconv pukes with an error.
It would be a wonderful development to have an RFC on the preferred
string representation of various objects as returned by the driver so
that when using ANSI SQL with PDO you can expect the same
representation across all drivers.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
I realize as the guy who has to deal with the driver code and what it
should do for people not following the advise below, it's probably
preaching to the choir, but...
Read the below comments this way: Anybody dumb enough to rely on the
kind of stuff you are asking about is already in Big Trouble (tm).
I realize that non Zend types would have to be returned as a string
representation.
At the risk of repeating myself, even Zend types aren't going to match
up -- The devil is in the details. The range for an INT in the DB
won't match the range for a Zend INT, for at least some databases,
almost for sure. I know 2s complement is 2s complement all over, but
there has to be SOME DB out there that has a range +/- 1 compared to
Zend INT.
The hangups I am having is with large objects returned
as streams in some drivers (but not dblib)
I never really use large objects, as anything that large doesn't
belong in the database in the first place... :-)
Rule Of Thumb:
If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
doesn't belong in the DB.
Put it in the custom highly-optimized specialized database engine
commonly known as "the file system" where it belongs. :-)
and inconsistent date/time
string representations across drivers depending on server
configuration files (freetds.conf).
Ewww... I generally use the DB date format feature to format dates in
a consistent manner, rather than rely on whatever random date/time
output the DB/driver chooses.
Another BIG issue I am having when using strings with DBLIB is that
they go through iconv, destroying binary values when translated to the
server character set from the assumed latin1 PHP client character set.
SQL Server for some reason allows characters to be stored in a
varchar/text fields even though the character is not defined in the
servers code page, whereas iconv pukes with an error.
I'm not an i18n expert, but...
Why is iconv being injected at this point?!
And why is PHP client library using latin1 for data that just isn't
latin1? That's just asking for problems...
I would expect any driver to just give me the raw data from the
database, in the charset defined by the DB, and not to try to
down-sample it to some other charset for me...
Though I guess if you've told the PHP client to make it be 'latin1'
the best it can do is trash it through iconv and you get what asked
for...
My only answer to that is to change your code to not ask for 'latin1'
in the first place, when the data isn't latin1. Change the PHP client
charset to what it ought to be, and get the data you wanted, not some
lossy down-sampled useless conversion of the data you wanted.
I cannot comment on SQL Server behaviour with respect to the "servers
code page" [sic], whatever that is, except to say that MySQL lets you
define your charset on a table by table basis, and, I think, in recent
versions, even on a field by field basis. OpenSource ftw, perhaps? :-)
It would be a wonderful development to have an RFC on the preferred
string representation of various objects as returned by the driver so
that when using ANSI SQL with PDO you can expect the same
representation across all drivers.
I'm all for documenting what SHOULD happen across all drivers, if
a) the docs are sensible, and
b) it can be implemented in all drivers
I suspect that even a) would generate a TON of discussion on this list
that would never be resolved, and that b) is simply not possible due
to some really brain-dead drivers.
But that's just my naive "gut" talking, with no real specific knowledge.
ymmv
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
I realize as the guy who has to deal with the driver code and what it
should do for people not following the advise below, it's probably
preaching to the choir, but...Read the below comments this way: Anybody dumb enough to rely on the
kind of stuff you are asking about is already in Big Trouble (tm).I realize that non Zend types would have to be returned as a string
representation.At the risk of repeating myself, even Zend types aren't going to match
up -- The devil is in the details. The range for an INT in the DB
won't match the range for a Zend INT, for at least some databases,
almost for sure. I know 2s complement is 2s complement all over, but
there has to be SOME DB out there that has a range +/- 1 compared to
Zend INT.The hangups I am having is with large objects returned
as streams in some drivers (but not dblib)I never really use large objects, as anything that large doesn't
belong in the database in the first place... :-)Rule Of Thumb:
If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
doesn't belong in the DB.
Put it in the custom highly-optimized specialized database engine
commonly known as "the file system" where it belongs. :-)
FWIW, large objects cannot be used in ORDER BY in MSSQL, and
relational integrity is best achieved by having your data in a
-relational- database.
Think mugshots, digitized signatures, etc. I really do not wish to
cycle through a record set to do a pass to delete the images on disk
by filename reference and then run another SQL to delete the records.
and inconsistent date/time
string representations across drivers depending on server
configuration files (freetds.conf).Ewww... I generally use the DB date format feature to format dates in
a consistent manner, rather than rely on whatever random date/time
output the DB/driver chooses.
And what ANSI SQL date conversion function would you suggest to
outputa consistent string date/time? CAST(date as varchar)?
Inconsistent at best across MSSQL, Oracle, PostgreSQL.
Another BIG issue I am having when using strings with DBLIB is that
they go through iconv, destroying binary values when translated to the
server character set from the assumed latin1 PHP client character set.
SQL Server for some reason allows characters to be stored in a
varchar/text fields even though the character is not defined in the
servers code page, whereas iconv pukes with an error.I'm not an i18n expert, but...
Why is iconv being injected at this point?!
Because all data on the wire from TDS is UTF16, including query strings.
And why is PHP client library using latin1 for data that just isn't
latin1? That's just asking for problems...
Theoretically I could ask for UTF8, but then I don't want to have to
run utf8_decode/utf8_encode on all query strings, returned data, etc
when the other drivers do not return unicode to PHP.
I would expect any driver to just give me the raw data from the
database, in the charset defined by the DB, and not to try to
down-sample it to some other charset for me...Though I guess if you've told the PHP client to make it be 'latin1'
the best it can do is trash it through iconv and you get what asked
for...
iconv is implemented in the freetds library outside of PHP. I guess I
could copy all of the freetds library code into pdo_dblib to avoid
iconv and external dependencies (making it a native driver)? It was a
side thought in order to get pdo_dblib working on Windows.
My only answer to that is to change your code to not ask for 'latin1'
in the first place, when the data isn't latin1. Change the PHP client
charset to what it ought to be, and get the data you wanted, not some
lossy down-sampled useless conversion of the data you wanted.I cannot comment on SQL Server behaviour with respect to the "servers
code page" [sic], whatever that is, except to say that MySQL lets you
define your charset on a table by table basis, and, I think, in recent
versions, even on a field by field basis. OpenSource ftw, perhaps? :-)
MSSQL allows per table and per column code pages in recent versions.
As far as OpenSource DBMS', I support what my clients run, not what I
want them to run. If I had my choice, I would be running PostgreSQL.
It would be a wonderful development to have an RFC on the preferred
string representation of various objects as returned by the driver so
that when using ANSI SQL with PDO you can expect the same
representation across all drivers.I'm all for documenting what SHOULD happen across all drivers, if
a) the docs are sensible, and
b) it can be implemented in all driversI suspect that even a) would generate a TON of discussion on this list
that would never be resolved, and that b) is simply not possible due
to some really brain-dead drivers.But that's just my naive "gut" talking, with no real specific knowledge.
ymmv
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Stanley Sufficool wrote:
Rule Of Thumb:
If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
doesn't belong in the DB.
Put it in the custom highly-optimized specialized database engine
commonly known as "the file system" where it belongs.:-)
FWIW, large objects cannot be used in ORDER BY in MSSQL, and
relational integrity is best achieved by having your data in a
-relational- database.Think mugshots, digitized signatures, etc. I really do not wish to
cycle through a record set to do a pass to delete the images on disk
by filename reference and then run another SQL to delete the records.
The first brick wall I hit when simply trying to use PDO was this one. On
firebird big text fields are BLOB ( oracle is the same - CLOB ) and I simply
want to read them as strings, but PDO 'optimizes' them as streams. Text search
is best handled IN the database and the content needs to be there to search on
or create indexes on. So while keeping all the binary content on my websites in
the file system is acceptable, doing that with the text is simply wrong. ( Until
perhaps a reach the point when an external text search option WOULD be more
efficient ;) )
Of cause the character set used for that data is then the next problem and has
to be unicode internally since even little things like addresses need to be able
to accept international users ... I don't have many Chinese/Japanese customers,
but the address book can at least handle them :)
In the database
Rule one ... times are all UTC
Rule two ... text is all unicode
I still can't simply switch between the generic firebird driver and the PDO one
in ADOdb so using PDO is academic at the moment. ADOdb does a GOOD job of
managing the data types and I can switch between most db's with very little
problem ... data wise ... it's always going to be the SQL that is the real
problem, but with care that can be made reasonably generic as well as long as
one bothers to think about that using PDO. Most 'conversions' simply break what
was good cross db sql to 'simplify' things for PDO and then actually LOOSE
access to most other db's :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Stanley Sufficool wrote:
Rule Of Thumb:
If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
doesn't belong in the DB.
Put it in the custom highly-optimized specialized database engine
commonly known as "the file system" where it belongs.:-)FWIW, large objects cannot be used in ORDER BY in MSSQL, and
relational integrity is best achieved by having your data in a
-relational- database.Think mugshots, digitized signatures, etc. I really do not wish to
cycle through a record set to do a pass to delete the images on disk
by filename reference and then run another SQL to delete the records.The first brick wall I hit when simply trying to use PDO was this one. On
firebird big text fields are BLOB ( oracle is the same - CLOB ) and I simply
want to read them as strings, but PDO 'optimizes' them as streams. Text
search is best handled IN the database and the content needs to be there to
search on or create indexes on. So while keeping all the binary content on
my websites in the file system is acceptable, doing that with the text is
simply wrong. ( Until perhaps a reach the point when an external text search
option WOULD be more efficient ;) )
PDO "optimizes" as a stream because PHP may be limited in memory and a
full fetch on a large object could be upwards of 2 GB. Regardless of
preferences on filesystem vs database storage of LOBs, there are
plenty of people using large objects in the database that are suitable
for sequential stream access.
Of cause the character set used for that data is then the next problem and
has to be unicode internally since even little things like addresses need to
be able to accept international users ... I don't have many Chinese/Japanese
customers, but the address book can at least handle them :)In the database
Rule one ... times are all UTC
Rule two ... text is all unicode
Rule three ... expect that rules 1 and 2 won't be followed by whoever
designed the database before you and everything will be local specific
and varchar.
I still can't simply switch between the generic firebird driver and the PDO
one in ADOdb so using PDO is academic at the moment. ADOdb does a GOOD job
of managing the data types and I can switch between most db's with very
little problem ... data wise ... it's always going to be the SQL that is the
real problem, but with care that can be made reasonably generic as well as
long as one bothers to think about that using PDO. Most 'conversions' simply
break what was good cross db sql to 'simplify' things for PDO and then
actually LOOSE access to most other db's :(--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Stanley Sufficool wrote:
Stanley Sufficool wrote:
Rule Of Thumb:
If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
doesn't belong in the DB.
Put it in the custom highly-optimized specialized database engine
commonly known as "the file system" where it belongs.:-)FWIW, large objects cannot be used in ORDER BY in MSSQL, and
relational integrity is best achieved by having your data in a
-relational- database.Think mugshots, digitized signatures, etc. I really do not wish to
cycle through a record set to do a pass to delete the images on disk
by filename reference and then run another SQL to delete the records.The first brick wall I hit when simply trying to use PDO was this one. On
firebird big text fields are BLOB ( oracle is the same - CLOB ) and I simply
want to read them as strings, but PDO 'optimizes' them as streams. Text
search is best handled IN the database and the content needs to be there to
search on or create indexes on. So while keeping all the binary content on
my websites in the file system is acceptable, doing that with the text is
simply wrong. ( Until perhaps a reach the point when an external text search
option WOULD be more efficient ;) )PDO "optimizes" as a stream because PHP may be limited in memory and a
full fetch on a large object could be upwards of 2 GB. Regardless of
preferences on filesystem vs database storage of LOBs, there are
plenty of people using large objects in the database that are suitable
for sequential stream access.
BUT at least having a switch to disable that action would be nice?
BOTH actions are required SELECTIVELY by field if one database uses a large text
field while the other uses a BLOB for the same size field. Current ports of
projects TO PDO fall flat because Firebird and Oracle can't then access the text
fields!
Of cause the character set used for that data is then the next problem and
has to be unicode internally since even little things like addresses need to
be able to accept international users ... I don't have many Chinese/Japanese
customers, but the address book can at least handle them :)In the database
Rule one ... times are all UTC
Rule two ... text is all unicodeRule three ... expect that rules 1 and 2 won't be followed by whoever
designed the database before you and everything will be local specific
and varchar.
In that case the first step is to clean up the mess to sort the problems out
that those bad practices have forced on the 'project'. As soon as I stripped all
of the 'server time' crap from the original tikiwiki some time ago making a
working cross timezone calendar was actually possible ... up until then it was
always wrong for half of the year in some areas :)
But porting a project CURRENTLY to PDO is not a sensible way to tidy things up :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Stanley Sufficool wrote:
On Fri, Nov 5, 2010 at 1:28 AM, Lester Cainelester@lsces.co.uk wrote:
Stanley Sufficool wrote:
Rule Of Thumb:
If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it
doesn't belong in the DB.
Put it in the custom highly-optimized specialized database engine
commonly known as "the file system" where it belongs.:-)FWIW, large objects cannot be used in ORDER BY in MSSQL, and
relational integrity is best achieved by having your data in a
-relational- database.Think mugshots, digitized signatures, etc. I really do not wish to
cycle through a record set to do a pass to delete the images on disk
by filename reference and then run another SQL to delete the records.The first brick wall I hit when simply trying to use PDO was this one. On
firebird big text fields are BLOB ( oracle is the same - CLOB ) and I
simply
want to read them as strings, but PDO 'optimizes' them as streams. Text
search is best handled IN the database and the content needs to be there
to
search on or create indexes on. So while keeping all the binary content
on
my websites in the file system is acceptable, doing that with the text is
simply wrong. ( Until perhaps a reach the point when an external text
search
option WOULD be more efficient ;) )PDO "optimizes" as a stream because PHP may be limited in memory and a
full fetch on a large object could be upwards of 2 GB. Regardless of
preferences on filesystem vs database storage of LOBs, there are
plenty of people using large objects in the database that are suitable
for sequential stream access.BUT at least having a switch to disable that action would be nice?
BOTH actions are required SELECTIVELY by field if one database uses a large
text field while the other uses a BLOB for the same size field. Current
ports of projects TO PDO fall flat because Firebird and Oracle can't then
access the text fields!
Seems simple to me, with the option to restrict to a specific memory footprint.
http://php.net/manual/en/function.stream-get-contents.php
Of cause the character set used for that data is then the next problem
and
has to be unicode internally since even little things like addresses need
to
be able to accept international users ... I don't have many
Chinese/Japanese
customers, but the address book can at least handle them :)In the database
Rule one ... times are all UTC
Rule two ... text is all unicodeRule three ... expect that rules 1 and 2 won't be followed by whoever
designed the database before you and everything will be local specific
and varchar.In that case the first step is to clean up the mess to sort the problems out
that those bad practices have forced on the 'project'. As soon as I stripped
all of the 'server time' crap from the original tikiwiki some time ago
making a working cross timezone calendar was actually possible ... up until
then it was always wrong for half of the year in some areas :)
Unless there is an existing client application that uses the database
in it's current state. The example here is a supplemental application
that has to co-exist with another ancient application until all
functionality has been replicated. In this case, the applications data
only exists in one timezone and in one language/code page.
But porting a project CURRENTLY to PDO is not a sensible way to tidy things
up :(--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
And why is PHP client library using latin1 for data that just isn't
latin1? That's just asking for problems...Theoretically I could ask for UTF8, but then I don't want to have to
run utf8_decode/utf8_encode on all query strings, returned data, etc
when the other drivers do not return unicode to PHP.
Have a look at:
https://open-mv.googlecode.com/svn/trunk/classes/database/drivers/
I've solved most of these problems though not with PDO* drivers.
I think you'll get the consistency you need for "2 interchangeable and have
PHP/PDO applications run the same on Win32 and Linux" only minus the
PDO/PDO_DBLIB part.
In my opinion, PDO already does too much "abstraction magic", it would be
great if PDO2? could expose somehow:
static inline void fetch_value()
so that in userland you could deal with custom data types and override how
the data type bindings happen.
That would be some much needed flexibility to actually create a "database
abstraction" layer vs the pdo "data-access" layer.
My only answer to that is to change your code to not ask for 'latin1'
in the first place, when the data isn't latin1. Change the PHP
client
charset to what it ought to be, and get the data you wanted, not
some lossy down-sampled useless conversion of the data you wanted.I cannot comment on SQL Server behaviour with respect to the
"servers code page" [sic], whatever that is, except to say that
MySQL lets you define your charset on a table by table basis, and, I
think, in
recent
versions, even on a field by field basis. OpenSource ftw, perhaps?
:-
)MSSQL allows per table and per column code pages in recent versions.
As far as OpenSource DBMS', I support what my clients run, not what I
want them to run. If I had my choice, I would be running PostgreSQL.
Per column code pages / collation is actually part of SQL92 (postgresql
doesn't support it, mysql, mssql,.. does)
In windows, the SQL native driver will properly convert everything to UTF-8.
In unix, FreeTDS should do the conversion correctly, have you run into
problems? Is this related to the PDO driver?