Hello, On 07/25/2002 04:35 PM, Andrew Hill wrote: > Manual, > > Certainly - please help us pinpoint any issues. > > Dan Kalowsky has done some great work in resolving lingering ODBC issues > in PHP, and I help in my way with testing and iODBC support. > > I respect the work you have done with Metabase, but it's a fallacy to > suggest that ODBC is "weak" - some ODBC drivers are indeed week, but a > proper driver provides more complete functionality than even native > drivers, and is often faster.
Andrew you ought to try developing really portable Web applications with PHP using ODBC so you can understand better what I am talking. The real problem is that ODBC was not meant for addressing specifically the actual needs of Web development. The ODBC driver was the most frustrating driver that I developed for Metabase. The problem is that ODBC API does not expose enough information from the underlying database so Metabase could figure how to implement some abstracted features. For instance, Metabase abstracts sequences. If the underlying database supports auto_increment fields, Metabase creates a separate table with a single auto_increment field to emulate a sequence. So far, so good. But how do I retrieve the last inserted number in a database independent way? Is it possible at all with ODBC API? Even if it is possible, I can't see support for the in ODBC API PHP functions. Another issue is selecting specific ranges of result rows. Doing this efficiently depends a lot on the underlying database. In MySQL we use LIMIT. On MS-SQL I use server side cursors. Other database have special keywords that prevent hogging the server or the database connecting sending unnecessary query result data. I know ODBC has several cursor models. Client side cursors are what Metabase ODBC uses already, but that is not as efficient as using specific database keywords. Even if I can use a server side cursor, how can I know with the current ODBC API PHP functions tell if the ODBC driver is capable of using such cursors? There doesn't seem to be a way to do it. Another thing are transactions. How do I tell if the underlying ODBC driver supports transactions? I know you can know it in C calling the ODBC API but there is no support to tell that from PHP. A major flop of ODBC PHP API are NULLs. How do I tell if a result set column has a NULL? It returns an empty string. How do I distinguish result set column empty string values from real NULLs? This needs to be fixed. Other than that, there were problems with odbc_gettypeinfo() more than once in the same script. Depending when you would free the result set it was either crashing PHP or returning an empty result set. I don't know if this was fixed since PHP 4.0.6 but the problem existed and prevented Metabase ODBC driver to figure how to correctly create tables and using correctly certain types of fields like blobs. There are probably other types of problems, but these are those that I remember immediately. Anyway, so far, it seems that using ODBC with PHP is pretty useless especially to write portable database independent applications until these problems are addressed. Because of this I will need to develop ODBC sub-drivers for Metabase that are aware of database specific details that PHP ODBC support is uncapable of providing. Regards, Manuel Lemos > -----Original Message----- > From: Manuel Lemos [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 25, 2002 1:39 PM > To: [EMAIL PROTECTED] > Subject: Re: [PHP-DB] Re: Unified DB Query function > > Hello, > > On 07/25/2002 02:34 PM, Andrew Hill wrote: > >>Pierre, >> >>Why not use ODBC functions everywhere? > > > I already told you before. ODBC is very weak API for real database > abstraction. To make it worse, PHP ODBC API is buggy and not as complete > > as it could be. > > As the maintainer of PHP ODBC support, if you are willing to do anything > > about it, I can help you to pin point the problems that need to be > addressed. Otherwise it is quite pointless to even consider using ODBC > in PHP unless it is your really alternative. > > Regards, > Manuel Lemos > > > >>Best regards, >>Andrew Hill >>Director of Technology Evangelism >>OpenLink Software http://www.openlinksw.com >>Universal Data Access & Virtuoso Universal Server >> >> >>-----Original Message----- >>From: Pierre-Alain Joye [mailto:[EMAIL PROTECTED]] >>Sent: Monday, July 01, 2002 1:01 PM >>To: [EMAIL PROTECTED] >>Cc: [EMAIL PROTECTED] >>Subject: Re: [PHP-DB] Re: Unified DB Query function >> >>On Mon, 01 Jul 2002 14:55:01 -0300 >>Manuel Lemos <[EMAIL PROTECTED]> wrote: >> >> >> >>>Hello, >>> >>>On 07/01/2002 06:46 AM, Casey Allen Shobe wrote: >>> >>> >>>>I'm trying to write a unified database query function for an >>> >>application I >> >> >>>>have which currently accesses data from both DB2 and Microsoft SQL >>> >>from a >> >> >>>>Linux server. I'm using ODBC functions for DB2, and Sybase >>> >>functions for >> >> >>>>Microsoft SQL. >>> >>>Why do you re-invent the wheeel and don't you use a database >> >>abstraction >> >> >>>package that handles the database differences of you, like for >> >>instance >> >> >>>Metabase: >>> >>>http://www.phpclasses.org/metabase >> >>Just because diversity rules in our world :). >> >>btw, do you have samples codes using the xxxxxDefinition methods in >>metabase ? >> >> >>pa >> -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
