Having now established that while functional, the firebird PDO driver is
simply not usable in real life applications, I've been reviewing the PDO
bug list initially to see if the problems I've encountered are already
listed.
First problem is simply identifying which bugs relate to which driver,
or the core package. But the main problem was simply trying to debug
things since every problem simply returned a white screen. Adding
another layer of try/catch got things a little under control, but while
perfectly valid SQL on firebird prepares and executes, fetching the
results seems to be a little problematic.
I think I am seeing the same problem with other drivers, so I don't
think this is simply a problem with firebird. pgsql, mssql, oci, odbc
and even mysql have some of the same bugs listed that I've been hitting
with firebird, so the question has to be exactly where a fault is?
The MAIN thing for which I have been asking for help relates to the use
of blob fields as large 'TEXT' fields, and oci is reporting the same bug
with the clob fields. The 'application' I have been trying to debug uses
a large text field in almost every table, and in the pre PDO environment
this mapped to a 'BLOB SUB_TYPE TEXT' in firebird(interbase) and CLOB in
oracle. Any attempt to use that in PDO simply fails, but I THINK this is
because I need to use a different 'bind' method for that field? How is
this then compatible cross database? It's bad enough trying to sort out
the mess of SQL without having to fix differences in handling data :(
Having given a good day or so to working through the PDO version, by
which time I had got the installer working, and even an import clipped
to 32000 characters for the large text fields ( using VARCHAR rather
than BLOB fields ) I was hitting problems with UNION and other more
complex SQL which required breaking down and doing some of the work in
PHP to get the required results.
Not making any real progress and not getting any replies to questions
here or on the general list I simply pulled the plug on the PDO 'class'
and replaced it with my well proven ADOdb 'class'. Within 8 hours over
Sunday night and Monday morning I had the core fully functional, and a
couple of hours yesterday restored most of the 'extras'. The main thing
being that the ADOdb error handling was identifying problems for which
PDO had just been a white screen!
I have no doubt that PDO works fine for many people, but since the
limited target that it had was for data abstraction IS this actually
achieved currently? Which drivers ARE fully functional, and what
outstanding bugs remain on each?
What is really needed is a wrapper like ADOdb that gets things under
control, rather than every project creating their own implementation.
This is the nice thing about ADOdb - it may be 'heavy' but it
'abstracts' the data in a way PDO seems unable to do.
(SQL abstraction is simply another matter)
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
