Oh drat - not the DBI connection string discussion again! On 7/4/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> 5. All details used to construct a connection handle should be > completely decomposed rather than shoved into an ungainly "data > source". Examples of what should be distinct (not all being > applicable at once) are: 1. the DBI driver module to use; 2. the > internet server IP address or domain name and port; 3. the locally > defined server device socket; 4. the locally defined service (eg, > ODBC or SQL*Net) name; 5. the file system file name; 6. the file > system directory name; 7. some other detail if any for fully in-RAM > databases; 8. the authorization identifier / user name; 9. the > password; 10. some other authorization credential, or channel > encryption details, or whatever else; 11. what kind of database or > what database product is being used, if known. If the DBI driver > talks to a client-configurable DBI proxy server, then, it should be > possible to nest a set of the above settings (eg, as a hash-ref) as > one part of the main settings given to the proxy client. > Only 1, 8 and 9 (driver name, user ID, password) apply to Informix databases - and you've missed out the other bit that applies - the database name, and optionally database server name hosting it (either 'dbase' or '[EMAIL PROTECTED]'). These are not the same as 2, 3, 4, 5, 6, 7, 10, or 11, and I can't think how any of them (except perhaps 10) could be applied to an IDS connection. Oh, and if you're going to enhance the connection, please ensure you cover challenge-response protocols (where you send an initial username/password and the authentication server comes back with a question such as "what is the number on your RSA key fob at the moment", and the hapless user has to type that information in, and the connection management code has to deal with this - callbacks and the like. So, as was discussed emphatically and exhaustively (in January 2005 in dbi-dev under 'Proposing an API for the extension for simplifying database connections'), this is not readily going to fly with the existing DBMS - specifically, not with IDS. Closed-source DBMS are *not* necessarily going to adapt to meet the needs of Perl and DBI. You can argue that's their loss - you may even be right. But you'll be limiting the acceptability of Perl + DBI in some respects. You'll also be annoying the hell out of me if you can't define a connection string that will work with Informix (I'm not too worried about the challenge-response stuff, though Informix can handle that). Oh - and DBI v2 should have support for scrollable cursors. -- Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h> Guardian of DBD::Informix - v2005.01 - http://dbi.perl.org "I don't suffer from insanity - I enjoy every minute of it."
