I have uploaded DBD::ODBC 1.46_2 to the CPAN today. As I previously
warned the 1.46_xx series of development releases contain a number of
Unicode fixes. You really should test this as without your feedback it
will be released eventually and these changes are substantial.
The changes since the last official release are:
DBD::ODBC::Changes - Log of significant changes to the DBD::ODBC
=head2 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
=head2 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.
Martin
--
Martin J. Evans
Wetherby, UK
