Re: [PHP4BETA] ODBC functions for PHP 4 improvements

Leo Baschy wrote: > > With PHP 4 about to go final I might as well make sure / take some responsibility for / > coordinate that ODBC works well in PHP 4. (Unless someone else tells me they want to do that right > now.) > It is a good idea to incorporate some changes before PHP4 goes final, see below. > To smooth the process (avoid conflicts) I would like to know (from _you_): > - are you using ODBC ? > - which database Adabas D > - which operating system Linux > - which Web server Apache 1.3.x > - which version of PHP 3.0.x, 4 > - are you changing PHP source yourself ? As for the PHP/Zend core: no > - are you actively changing PHP's ODBC functions Yes > - are you compiling yourself or are you using the built binary ? > (would you notice if something breaks?) Compile > - which compiler environment gcc > - whatever else you think matters > > Some of my agenda: > - Having written my code for PHP 3 I am now taking it over to PHP 4. > (Specifically support for calling SQL (stored) procedures and > getting output parameters back, and multiple result sets, > improved handling of large text.) Handling of output parameters is one thing I have on my list, but didn't want to introduce incompatibilities in the 3.0.x series. As for LOB handling, what are exactly your ideas on how to improve this? > - For PHP 4 I made closing a connection also close a result > (works if there is only one result open at a time for one connection, > which I think might be all the time), in case people forget. > See my previous mail on your cvs commit. > Some of the issues I think might be coming up: > - For myself I have added some more error checking, which is good, > but could scare people whose PHP / SQL code causes those errors; > mine were all quickly fixable in PHP or SQL This is a tricky issue, esp. if there are some drivers that have different approaches to error reporting. To not overly complicate the code, I decided to not do too much of error checking, since an error would get caught anyway in the next call to some SQLxxx function. The downside of this approach is that you could get misleading error messages. > - there might be different behavior on Windows vs. Unix, > MSSQL vs. Oracle, Apache vs. IIS, cgi exe vs. module, > regular vs. persistent connection etc. > Yes, esp. on Windows where additionally thread safety is required. Unfortunately, I'm a little bit stupid on getting PHP4 to run as an ISAPI extension with IIS/PWS. So if you or anybody else would like to do some testing/debugging on Win32, you' re welcome ;-) Generally, you always find annoying differences / bugs in ODBC drivers - just take a look at all those #defines in the odbc source. Of course, they only work if you are using the CLI libraries directly and not some DM where you won't know beforehand which driver is going to be used. It is nearly impossible to get a 100% working odbc module as this would require a huge amount of runtime checking which driver is used and to be sure even which version. (Q: "What's new with the new version?" A: "New bugs.") This would slow down ODBC even more when compared to native database access. -Andreas