Can't you set odbc_version to 2 as it looks like DBD::ODBC will then call
rc = SQLSetEnvAttr(imp_drh->henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)odbc_version, SQL_IS_INTEGER); instead of rc = SQLSetEnvAttr(imp_drh->henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER)SQL_OV_ODBC3, SQL_IS_INTEGER); Asking for ODBC 2 behavior affects SQL states and you get SQL_TYPE_TIMESTAMP, SQL_TYPE_DATE etc instead of SQL_TIMESTAMP. As far as I can see DBD::ODBC supports both. Martin -- Martin J. Evans Easysoft Ltd, UK Development On 08-Mar-2003 Jeff Urlwin wrote: > Dale, > > You might want to, at least temporarily, downgrade to 0.43, which will mean > that you should build it from the source. > > Unfortunately, there were a number of code changes that went along with > moving to 3.x for correctness, so I'd be surprised if it worked as a 2.x app > anymore, but if you build from the source, you may be able to take out the > SQLSetEnvAttr in the connect function. > > Jeff > >> -----Original Message----- >> From: Dale Durham [mailto:[EMAIL PROTECTED] >> Sent: Friday, March 07, 2003 2:27 PM >> To: '[EMAIL PROTECTED]' >> Subject: SQLSTATE ($h->state) mappings >> >> >> Is anyone working on (or is there a way to tell) the driver >> to pass ODBC 2.x state returns instead of 3.x (given the >> current DBD::ODBC driver is a 3.x 'app')? I have thousands of >> testcase that verify the $h->state() along with other returns >> such as $h->err. Once I upgraded to newer DBI and DBD::ODBC I >> now get ODBC 3.x state returns. Through ODBC, I can pass >> SQLSetEnvAttr to tell the driver to return ODBC 2.x states. >> How can I deal with this via DBI since DBD::ODBC does not >> have a function for this? >> >> Regards, >> Dale >>
