RE: [PHP-DEV] PDO_DBLIB Native PHP Type binding
| From: | Jonathan Bond-Caron | Date: | Fri, 05 Nov 2010 13:26:45 +0000 |
| Subject: | RE: [PHP-DEV] PDO_DBLIB Native PHP Type binding | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-50107@lists.php.net to get a copy of this message | ||
On Fri Nov 5 12:57 AM, Stanley Sufficool wrote:
> >
> > 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?