develooper Front page | perl.dbi.users | Postings from January 2013

Final development release of DBD::ODBC 1.42 series

Martin J. Evans
January 25, 2013 09:54
Final development release of DBD::ODBC 1.42 series
Message ID:
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


   Not all modules used in test code were specified in build_requires.

=head2 Changes in DBD::ODBC 1.42_4 January 21 2013


   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


   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


   Changed any use of if SvUPGRADE to remove the if test as per email
   from Dave Mitchell and posting at

=head2 Changes in DBD::ODBC 1.42_1 December 12 2012


   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.


   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.


   New odbc_rows statement method (see above).


   New rt_81911.t test case.

=head2 Changes in DBD::ODBC 1.42_0 November 28 2012


   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


   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 J. Evans
Easysoft Limited Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About