PDO Ground Rules

OK - Until Ard bring pdo_firebird in line with the current pdo code, I am a little stuck. I've spent more time going back over what I CAN test, and have produced a 'fault report' for Ard, but a few more questions pop up. DON'T chew my head off, because it may simply be that I can't yet test something. 1/ The connection string is provided via a connect form, which supplies the driver, and the database details - in pdo format. Question - can I get the driver name from the pdo object, or do I need to maintain that outside the object so that I can apply driver specific checks? ( Additional getAttribute values with string returns? ) 2/ We have 'charset=' as an option in the connection string, which obviously requires database specific values. 'role=' is available in the pdo_firebird driver, and other options will be added. So we can modify connection information, but this can only be managed via the connection string? Also, again, this is not accessible from within the created pdo object and so needs to be maintained externally? (getAttribute again? PDO_ATTR_CHARSET has been mentioned but is not listed in the docs) 3/ I have to fetch data that actually has an existing record in order to get the fields? I can't select a record, and if it does not exist populate the fields identified to provide the insert query? ( pdo_firebird does not return an 'empty' record, only a false, and getColumnMeta is not currently returning anything - I presume that this will be driver specific content anyway? ) Don't we need some secondary manual pages to start documenting the driver specific variations? Connection details, where a function is emulated or simply unavailable, what defaults are assumed/set, etc. I'm still not sure about things, but if

PDO isn't a replacement for ADOdb, it's a future replacement for ext/mysql, ext/pgsql, ext/oci8, ext/odbc, etc. etc. etc. as Wez says, then I'm still not getting the whole picture :(

-- Lester Caine ----------------------------- L.S.Caine Electronic Services