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

Reply via email to