I have uploaded DBD::ODBC 1.38_3 to CPAN. As no new issues have been reported my intention is to make this a full 1.39 in the next week or so. There is nothing too exciting in 1.38_3 but the previous 1.38 development releases contain some interesting enhancements and changes. Please let me know if you find any issues. The changlog for the 1.38 series is below:

=head1 NAME

DBD::ODBC::Changes - Log of significant changes to the DBD::ODBC

As of $LastChangedDate: 2012-05-27 12:09:52 +0100 (Sun, 27 May 2012) $

$Revision: 10667 $

=head2 Changes in DBD::ODBC 1.38_3 June 25 2012

  [BUG FIXES]

  Added encoding line to this file to stop pod test from complaining.

  [DOCUMENTATION]

  Added link to 64 bit ODBC article.

  Fixed some typos in the pod.

  [MISCELLANEOUS]

  Made pod.t an author test.

=head2 Changes in DBD::ODBC 1.38_2 May 24 2012

  [ENHANCEMENTS]

  Added support for Oracle TAF (assuming your ODBC driver supports it)
  - see odbc_taf_callback.

=head2 Changes in DBD::ODBC 1.38_1 May 19 2012

  [BUG FIXES]

  Fixed rt 77283. If you overrode the bind type as SQL_INTEGER in a bind_col
  call AFTER previously binding as another type (or not specifying a type)
  you would not get the right value back. This also fixes the DiscardString
  bind_col attribute for SQL_INTEGER binds (however, see below as DiscardString
  is no longer required for SQL_INTEGER).

  Fixed some format specifiers in trace calls.

  [CHANGE IN BEHAVIOUR]

  DBD::ODBC allowed you to change the bound column type in bind_col
  after the column was already bound. It now does not allow this
  and issues a warning.

  You can nolonger override the bound column type (except with
  SQL_NUMERIC and SQL_DOUBLE). All columns are now bound as either
  SQL_C_LONG (integer columns) or SQL_C_[W]CHAR (all other columns).
  If you are calling bind_col with a TYPE => xxx it most likely did
  not do what you expected and you should examine it carefully with a
  view to removing it altogether. As a result you no longer have to
  override the bind type for MS SQL Server XML columns - these will be
  bound as SQL_C_CHAR or SQL_C_WCHAR depending on whether Unicode is
  enabled.

  Integer columns are now bound as SQL_C_LONGs and not as before,
  SQL_C_CHAR. This should not matter to you but if you were adding 0
  to your integer columns retrieved to make them behave like integers
  you should nolonger need to do it.

  [OTHER]

  Added some missing SQL_C_xxx types to S_SqlCTypeToString internal
  function. This only affects tracing.

  Some tests in 08bind were skipped when they did not need to be.

  sql_type_cast tests rewritten due to fixes above.

Martin

Reply via email to