White screen usually means a segmentation fault - php crashed. I guess the best option you have is to repeat all these situations when it crashed and to get a backtrace and post it under the relevant bug or create a new one. I also had a disappointing experience with PDO. I used before adodb as well and migrated to pdo and tried to have an app working with both mysql & oracle but the pdo/oci combination didnt work for me. I hit a CLOB problem reported already (I just added my comment & trace): http://bugs.php.net/bug.php?id=44589 Unfortunately if you just walk through the "php 5 bug summary report" you will see that PDO list is one of the longest (and it always have been). What we can do is at least report the problems and hope that someone skilled will fix them (this is by no means a criticism to the php team, don't get it this way).
Vesselin Kenashkov On Tue, Sep 15, 2009 at 10:04 AM, Lester Caine <les...@lsces.co.uk> wrote: > 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 > > -- Vesselin Kenashkov developer at www.webstudiobulgaria.com
