Justtechjobs.com Find a programming school near you






Online Campus Both


php-db | 2002091

[PHP-DB] Re: [PHP-DEV] RFC: ODBC and PHP From: Shane Caraveo (shane <email protected>)
Date: 09/10/02

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."
> dank-nom <email protected> - "Streets of Philadelphia",
> Kalowsky <email protected> Bruce Springsteen
>
>
> 

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php