I have just uploaded DBD::ODBC 1.47 to the CPAN.

This release does contain significant changes in behaviour for unicode builds 
of DBD::ODBC so I hope when I warned you months ago you tested it.

Thanks to everyone on the dbi-dev list and irc that helped me work my way 
through the unicode issue.

I'm now going to sit back and wait for the usual rush of reports from everyone 
who didn't test it.

See below for changes since last full release.

Martin

1.47 2014-02-19

  Full release of the 1.46 development releases.

  [MISCELLANEOUS]

  Just some tidying up of dbdimp.c - shouldn't make a difference to anyone.

  Further changes to this change file to make it CPAN::Changes spec.
  NOTE the changes.cpanhq.com site does not yet support "unknown" for
  dates.

1.46_2 2013-12-17

  [BUG FIXES]

  When built with unicode support and odbc_old_unicode is not enabled
  columns reported as SQL_LONGVARCHAR were not by default bound as
  SQL_WCHAR and hence were not returned correctly unless the bind was
  overridden.

  [MISCELLANEOUS]

  Added test 90_trace_flag.t

1.46_1 2013-11-16

  [CHANGE IN BEHAVIOUR]

  As warned in release 1.45, the binding of unicode parameters to
  char/varchar columns has changed significantly. If you don't attempt
  to insert unicode into char/varchar columns or if you only inserted
  unicode into nchar/nvarchar columns you should see no difference.
  From this release, unicode data inserted into
  char/varchar/longvarchar columns is bound as SQL_WCHAR and not
  whatever the driver reports the parameter as (which is mostly
  SQL_CHAR).

  Previously if DBD::ODBC received an error or (SQL_SUCCESS_WITH_INFO)
  from an ODBC API call and then the driver refused to return the
  error state/text DBD::ODBC would issue its own error saying "Unable
  to fetch information about the error" and state IM008. That state
  was wrong and has been changed to HY000.

  [BUG FIXES]

  Some drivers cannot support catalogs and/or schema names in
  SQLTables.  Recent changes set the schema/catalog name to the empty
  string (good reasons below) which causes "optional feature not
  implemented" from MS Access (which does not support schemas - even
  for a simply ping (which uses SQLTables)). Now we call
  SQLCATALOG_NAME and SQLSCHEMA_USAGE on connect to ascertain support
  which modifies SQLTables call.

  [MISCELLANEOUS]

  Added test 45_unicode_varchar.t for MS SQL Server only so far.

Reply via email to