[PHP-DB] Re: [PHP-DEV] RFC: ODBC and PHP
Dan Kalowsky wrote: On Tue, 10 Sep 2002, Shane Caraveo wrote: Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. This is a tricky question really. Theoretically, yes it should be possible to allow this. You may run into issues with some of the result sets, but the connections should still be the same. You couldn't really do it with a function like odbc_set_version, as my understanding of ODBC states you must declare which version type you are using at compile time. If you have some documentation stating otherwise, I'd be interested in reading it. It depends on if a driver manager is involved, if it is, you can select the behavour you want before allocating the connect handle. But I wouldn't expect that many of the changes would be that important, IF you use a driver manager, if not, then you have to choose which set of ODBC API's you are compiling to. The reality is, I don't know. All ODBC3 drivers should be able to utilize the deprecated functionality just fine, but the mapping is an unknown and dependent upon vendor implementation. Going the other way, of course, is not going to work. Not allways the case, again if a DM is there then yes agreed, but without the DM, there are ODBC 3 drivers that don't implement the older API, they assume that the DM will tidy this up for them. But I don't see a reason to keep such BC at this point. The problem with the current system can be seen with bugs in the result sets. The one area specifically mentioned above. Users are still going to ask Why doesn't my select work? while using NTEXT or something non-compliant. The CURSOR type cannot be changed with the current system. This in itself leads to a slower implementation, a (unnecessarily) larger memory footprint, and in DB2 systems a memory leak. Having a real way of changing the cursor type would IMHO fix a lot of the current php_odbc problems. Hey at least I haven't gone as drastic as I originally thought, and asked to drop support specific for things like DB2, Solid, Empress, etc, and only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC). :) Although I still think that would make the most sense and be the easiest to support on our end of things. Well I am of course biased :-) but I still can't see the real downside of that... Perls DBD:ODBC for example has come to the conclusion that DM's do more good than harm. --- Nick Gorham -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP-DEV] RFC: ODBC and PHP
Hi Dan, On 11/09/02, Dan Kalowsky [EMAIL PROTECTED] wrote: - It will support ODBC v 3.0 and greater only. With the needs of many DBs ... I would like to add this into the current PHP system, to allow users to start playing with and testing as well. Well probably just as soon as I finish some more of the odbc2_exec/odbc2_execute() cleanups. This code is I know this probably isn't the kind of comment you want just now, but... If this is to support ODBC v3+, why not call the functions odbc3_xxx instead of odbc2_xxx? I think this could help prevent some head-scratching a little later down the track. --Wez. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP-DEV] RFC: ODBC and PHP
On Wed, 11 Sep 2002, Wez Furlong wrote: I know this probably isn't the kind of comment you want just now, but... If this is to support ODBC v3+, why not call the functions odbc3_xxx instead of odbc2_xxx? I think this could help prevent some head-scratching a little later down the track. Well technically it's to move PHP's ODBC support further along. I've just been calling it ODBC2 locally here to make life easier when I talk to other people (as in v2 of the PHP ODBC lib). What I'm thinking I'd really like to see is ODBC move to PECL or something like that, to allow me to keep it in a different release schedule (as ODBC standards don't change that rapidly). But I've heard some complaints against such ideas, so I haven't pushed it (yet). Anyways naming convention can be changed very easily. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springstreen -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP-DEV] RFC: ODBC and PHP
Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. Shane Dan Kalowsky wrote: To Whom It May Concern, I've been working for the last few months (delayed often, but mostly the last few weeks) on what I've been tenatively calling ODBC2. Basically this is what I'd like to see PHP v 5 have as it's default ODBC system. Some general notes about it: - It will break BC. I have tried to conform and keep things the same, but I'm not making any promises to keep BC at this time. - It will support ODBC v 3.0 and greater only. With the needs of many DBs to include larger typesets (like TEXT, NTEXT, IMAGE, etc) and UNICODE, I see this as being a necessity. Some implementation notes: - So far my testing is being done using iODBC, unixODBC, and Windows ODBC drivers. I have no way of checking any of the others... help on this front would be appriciated. Some of the features already added to it: - Ability to control the ODBC environment handles before and after a connection is created. - Ability to specify a CURSOR for use in statements. - More strongly enforced safe_mode restrictions. - The ability to connect to data sources without being defined locally. - A user can force the PHP system to create a new connection now. - An attempt to make the ODBC API look more like the MySQL/PostgreSQL APIs feature setwise. - An option for the user to turn on which can allow dynamic sizing of a result set text field (currently it's static). - Use of the default_user, default_db, and default_passwd in the php.ini. - Hopefully more detailed error messages. - Native support for returning results from functions, and SQL based constructs (outside of SELECT statements). If you have any specific functionality you would like to see, please send it to me, and I will see what I can do about adding this in. I would like to add this into the current PHP system, to allow users to start playing with and testing as well. Well probably just as soon as I finish some more of the odbc2_exec/odbc2_execute() cleanups. This code is not optimized in any way, shape, or form. It's not even believed to work with a lot of systems. Because of this, I would like to hear back commentary back on any suggested recourse from those who've done this already. Hopefully this will prove to be a useful change, and people will be happy :) As always send your comments to me. --- Dan Kalowsky I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin. [EMAIL PROTECTED] - Streets of Philadelphia, [EMAIL PROTECTED] Bruce Springsteen -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP-DEV] RFC: ODBC and PHP
On Tue, 10 Sep 2002, Shane Caraveo wrote: Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. This is a tricky question really. Theoretically, yes it should be possible to allow this. You may run into issues with some of the result sets, but the connections should still be the same. You couldn't really do it with a function like odbc_set_version, as my understanding of ODBC states you must declare which version type you are using at compile time. If you have some documentation stating otherwise, I'd be interested in reading it. The reality is, I don't know. All ODBC3 drivers should be able to utilize the deprecated functionality just fine, but the mapping is an unknown and dependent upon vendor implementation. Going the other way, of course, is not going to work. But I don't see a reason to keep such BC at this point. The problem with the current system can be seen with bugs in the result sets. The one area specifically mentioned above. Users are still going to ask Why doesn't my select work? while using NTEXT or something non-compliant. The CURSOR type cannot be changed with the current system. This in itself leads to a slower implementation, a (unnecessarily) larger memory footprint, and in DB2 systems a memory leak. Hey at least I haven't gone as drastic as I originally thought, and asked to drop support specific for things like DB2, Solid, Empress, etc, and only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC). :) Although I still think that would make the most sense and be the easiest to support on our end of things. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DB] Re: [PHP-DEV] RFC: ODBC and PHP
Ok, then I would be for ODBC 3 for PHP 5 as the standard. An ODBC 2 extension can be shuttled out to PECL for those who may need it. But for BC issues, there is still the nameing convention. I would personaly prefer that the odbc functions stay odbc_*, rather than to start iterating through odbc2...odbc3 and so forth. Don't know an easy solution right now. Shane Dan Kalowsky wrote: On Tue, 10 Sep 2002, Shane Caraveo wrote: Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. This is a tricky question really. Theoretically, yes it should be possible to allow this. You may run into issues with some of the result sets, but the connections should still be the same. You couldn't really do it with a function like odbc_set_version, as my understanding of ODBC states you must declare which version type you are using at compile time. If you have some documentation stating otherwise, I'd be interested in reading it. The reality is, I don't know. All ODBC3 drivers should be able to utilize the deprecated functionality just fine, but the mapping is an unknown and dependent upon vendor implementation. Going the other way, of course, is not going to work. But I don't see a reason to keep such BC at this point. The problem with the current system can be seen with bugs in the result sets. The one area specifically mentioned above. Users are still going to ask Why doesn't my select work? while using NTEXT or something non-compliant. The CURSOR type cannot be changed with the current system. This in itself leads to a slower implementation, a (unnecessarily) larger memory footprint, and in DB2 systems a memory leak. Hey at least I haven't gone as drastic as I originally thought, and asked to drop support specific for things like DB2, Solid, Empress, etc, and only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC). :) Although I still think that would make the most sense and be the easiest to support on our end of things. --- Dan Kalowsky I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin. [EMAIL PROTECTED] - Streets of Philadelphia, [EMAIL PROTECTED] Bruce Springsteen -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
