On Thu, November 4, 2010 9:09 pm, Stanley Sufficool wrote:
On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch wrote:
On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote:
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
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
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
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.