I've just uploaded DBD::ODBC 1.42_5 to CPAN. I'm hoping this is going to be the final development release of the 1.42 series. If you rely on DBD::ODBC then please test it. The changes since the last full release are below. In particular note that there is a small change in behaviour.
=head2 Changes in DBD::ODBC 1.42_5 January 25 2013 [BUG FIXES] Not all modules used in test code were specified in build_requires. =head2 Changes in DBD::ODBC 1.42_4 January 21 2013 [ENHANCEMENTS] odbc_trace and odbc_trace_file are now full connection attributes so you can set them any time you like, not just in connect. =head2 Changes in DBD::ODBC 1.42_3 January 17 2013 [ENHANCEMENTS] Added odbc_trace_file and odbc_trace attributes to the connect method so you can now enable ODBC API tracing from the connect method instead of having to use the ODBC Driver Manager. These also only enable ODBC API tracing in the application which made the call unlike the ODBC Driver Manager settings. =head2 Changes in DBD::ODBC 1.42_2 December 17 2012 [MISCELLANEOUS] Changed any use of if SvUPGRADE to remove the if test as per email from Dave Mitchell and posting at http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2012-12/msg00424.html. =head2 Changes in DBD::ODBC 1.42_1 December 12 2012 [BUG FIXES] DBD::ODBC's ExecDirect method did not return an SQLLEN so if you managed to affect a massive number of rows it would be cast to an int and hence precision lost. [CHANGE IN BEHAVIOUR] When you called DBI's execute method and odbc_exec_direct was not set (the default) if you managed to affect more rows than would fit into an int you would get the incorrect count (NOTE on 32 bit platforms ODBC's SQLRowCount can only return a 32bit value anyway). You would get whatever casting an SQLLEN to an int would give you. The fix for this needs a change to DBI (see RT 81911) and the change would probably impact every DBD so until then DBD::ODBC will a) warn if an overflow occurs and Warn is set on the handle b) return INT_MAX and c) provide a new statement method odbc_rows which you can use to get the correct value. [ENHANCEMENTS] New odbc_rows statement method (see above). [MISCELLANEOUS] New rt_81911.t test case. =head2 Changes in DBD::ODBC 1.42_0 November 28 2012 [BUG FIXES] MS Access requires a longchar column to be bound using SQL_LONGVARCHAR. However, MS Access does not support SQLDescribeParam and we default to SQL_VARCHAR in this case. The point at which we switch to SQL_LONGVARCHAR was defaulted to 4000 (for MS SQL Server). We now default to SQL_LONGVARCHAR for MS Access when data is > 255. This means you can remove those {TYPE => SQL_LONGVARCHAR} from your bind_param calls for longchar columns in MS Access. I seem to have introduced a bug in the test suite for MS Access. The last test in the 09bind test binds dates as varchars (by default) and this cannot work in MS Access (it needs to be a timestamp). This test was skipped in the past and the skip got removed. [MISCELLANEOUS] Steffen Goeldner reported some issues with execute_array in DBD::Oracle where if ArrayTupleStatus was not specified and an error occurred DBD::Oracle did not do the right thing. As I used DBD::Oracle as a base when I wrote execute_for_fetch in DBD::ODBC I added tests to the test suite to ensure these issues did not exist in DBD::ODBC. Minor change to sql_type_cast.t test which attempts to insert an integer into a varchar. No databases so far have complained about this until we ran the test against Derby. Changed to use '100'. RT 80446 - fix spelling mistake - thanks to Xavier Guimar. Martin -- Martin J. Evans Easysoft Limited http://www.easysoft.com
