I have just uploaded a new test release of DBD::ODBC to CPAN. The focus
of this release is to add further unicode support to DBD::ODBC. For full
unicode support (namely ODBC connection strings) you will need a DBI
from subversion or you'll have to wait for Tim to release it but all
other unicode support is not dependent on DBI. A list of changes since
the last DBD::ODBC test release is included below.
As a reminder, to get full unicode support you will need a unicode aware
driver manager (like unixODBC or Microsofts driver manager) and you will
need to build DBD::ODBC with the -u switch (e.g., perl Makefile.PL -u).
Please let me know if you find any problems as this is probably the most
substantial release of DBD::ODBC in years and I'm sure there will be
some issues I've not found.
If you are too impatient to wait for CPAN you will find a copy here:
ftp://ftp.easysoft.com/pub/
=head2 Changes in DBD::ODBC 1.16_2 September 2, 2008
Removed szDummyBuffer field from imp_fbh_st and code in dbd_describe
which clears it. It was never used so this was a waste of time.
Changed the remaining calls to SQLAllocEnv, SQLAllocConnect and
SQLAllocStmt and their respective free calls to the ODBC 3.0
SQLAllocHandle and SQLFreeHandle equivalents.
Rewrote ColAttributes code to understand string and numeric attributes
rather than trying to guess by what the driver returns. If you see any
change in behaviour in ColAttributes calls you'll have to let me know
as there were a number of undocumented workarounds for drivers.
Unicode build of DBD::ODBC now supports:
=over
=item column names
The retrieval of unicode column names
=item SQL strings
Unicode in prepare strings (but not unicode parameter names) e.g.,
select unicode_column from unicode_table
is fine but
select * from table where column = :unicode_param_name
is not so stick to ascii parameter names if you use named parameters.
Unicode SQL strings passed to the do method are supported.
SQL strings passed to DBD::ODBC when the odbc_exec_direct attribute
is set will B<not> be passed as unicode strings - this is a limitation of
the odbc_exec_direct attribute.
=item connection strings
True unicode connection string support will require a new version
of DBI (post 1.607).
B<note> that even though unicode connection strings are
not supported currently DBD::ODBC has had to be changed to call
SQLDriverConnectW/SQLConnectW to indicate to the driver manager it's
intention to use some of the ODBC wide APIs. This only affects DBD::ODBC
when built for unicode.
=item odbcunicode trace flag
There is a new odbcunicode trace flag to enable unicode-specific
tracing.
=back
Skipped 40Unicode.t test if the ODBC driver is Oracle's ODBC as I
cannot make it work.
Changes internally to use sv_utf8_decode (where defined) instead of
setting utf8 flag.
Fix problems in the test when Test::NoWarnings is not installed.
Removed some unused variables that were leading to compiler warnings.
Changed a lot of tracing to use new odbcconnection flag
Changed to use dbd_db_login6_sv if DBI supports it.
Commented out a diag in 20SqlServer.t that was leading to confusion.
Added diag to 20SqlServer.t in mars test to explain why it may fail.
Various pod changes for clarification and to note odbc_err_handler is
deprecated.
Removed odbcdev trace flag - it was not really used.
New odbc_out_connect_string attribute for connections which returns
the ODBC driver out connection string.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
