Re: [PEPr] +1 for Database::DB_odbtp

On Fri, 10 Sep 2004, Daniel Convissor wrote: > On Thu, Sep 09, 2004 at 04:37:39PM -0400, Robert Twitty wrote: > > danielc's conditional vote... > > > > > I don't like how the 'username' DSN element contains all of this > > > information: $dsninfo['username'] = 'DRIVER={Microsoft Access Driver > > > (*.mdb)};DBQ=c:\NorthWind.mdb;UID=admin;PWD=;'; > > > That needs to be broken down into the proper elements in order to provide > > > portability/comprehendability with DB. > > ... snip ... > > > The second method permits complete portability/compatibiltiy with DB's > > connection scheme > > DB doesn't use a user interface file, so that's not portable. > This is correct, because it is used by the odbtp extension. The interface file is processed by the ODBTP C client library that was used to build the odbtp extension. The ODBTP interface file is analogous to FreeTDS's interface file. FreeTDS, as you know, was used to build the mssql and sybase extensions on Linux/UNIX. I stole the idea from FreeTDS in order to incorporate support for PHP's mssql functions within the odbtp extension. The odbtp.interface_file php.ini setting is used to specify the location of this file, which is exactly the same purpose of sybase.interface_file. The odbtp extension's use of the interface file is completely oblivious to DB. It is strictly determined by whether or not the 'username' DSN parameter is an ODBC driver connect string. For example: $dsninfo['phptype'] = 'odbtp'; $dsninfo['hostspec'] = 'myinterface'; $dsninfo['username'] = 'myusername'; $dsninfo['password'] = 'mypassword'; $dsninfo['database'] = 'mydatabase'; and $dsninfo = 'odbtp://myusername:mypassword@myinterface/mydatabase'; will cause the odbtp extension, not DB_odbtp, to connect to the ODBTP server with the aid of an interface. Also, in order to use a DB DSN string, an interface file must be created. Otherwise, the odbtp extension will generate an error stating that it was unable to open the interface file. -- snip --- > Sure it can. Have the user pass a DB standard DSN string OR array to > connect, but then have your connect() function merge the data into the > format necessary to make a connection to the server. That's what all > of the drivers do. > This strategy is not a problem for mapping to ODBC DSN connect strings: DSN=MyDSN;UID=MyUID;PWD=MyPWD; However it is more problematic for ODBC DSN-Less connect strings: DRIVER={SQL Server};SERVER=myserver;UID=myuid;PWD=mypwd;DATABASE=mydb;;NETWORK=DBMSSOCN; DRIVER={Microsoft Access Driver (*.mdb)};DBQ=c:\mydb.mdb;UID=admin;PWD=; DRIVER={Microsoft Visual Foxpro Driver};SOURCETYPE=DBC;SOURCEDB=c:\mydb.dbc;EXCLUSIVE=NO; DRIVER={Sybase ASE ODBC Driver};SRVR=myserver;UID=myuid;PWD=mypwd;DATABASE=mydb; DRIVER={IBM DB2 ODBC Driver};DATABASE=mydb;HOSTNAME=myhost;PORT=50000;PROTOCOL=TCPIP;UID=myuid;PWD=mypwd DRIVER={MySQL};SERVER=myserver;PORT=3306;OPTION=131072;STMT=;UID=myuid;PWD=mypwd;DATABASE=mydb; As you can see, DSN-Leess connect strings are too anarchal for full accomodation by DB's DSN spec. Unless, of course, there is something that I am missing. The DB odbtp driver would need to have apriori knowledge of every DBMS's ODBC DSN-Less connect string. So, the ODBTP interface concept was created to avoid this situation. -- bob