On Tue, 10 Sep 2002, Shane Caraveo wrote: > 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
Shane, I agree that the naming convention should stay the same. I'm only calling it that now so I can test it and reference it with other people. :) > > 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 > > > > > > > > >---------------------------------------------------------------< 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 Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
