martin-evans.me.uk Always finish the day on a success

I've uploaded DBD::ODBC 1.34_4 to CPAN.

This release contains all changes/fixes/enhancements since 1.33 and also the new odbc_getdigarec and odbc_getdiagfield methods.

=head2 Changes in DBD::ODBC 1.34_4 February 5 2012

[BUG FIXES]

* When odbc_getdiag* methods were added they installed themselves
into DBI but did not set IMP_KEEP_ERR so calling them cleared
DBI's errors.

=head2 Changes in DBD::ODBC 1.34_3 February 3 2012

[BUG FIXES]

* Linking against unixODBC was working by accident on most UNIX

I have uploaded DBD::ODBC 1.34_1 to CPAN. This release adds very experimental support for a native execute_for_fetch method to DBD::ODBC which means you can do multiple row inserts/updates/deletes much quicker than using DBI's default execute_for_fetch (so long as you are using execute_for_fetch or execute_array and using column-wise binding).

Native execute_for_fetch support can often be as much as 30 or 40 times faster in my experiments (depending on data sent and odbc_batch_size) when inserting rows and even more if you do it in a transaction and even faster if you disable index updates until after the commit. Read on for why.

By default DBD::ODBC will use the new execute_for_fetch and there are some differences between what happens when you use DBD::ODBC with DBI's default execute_for_fetch and DBD::ODBC's. To disable the ODBC one you can set the new odbc_disable_array_operations attribute. I've listed the potential difference below. I'd love people to test this. It may be missing some special workarounds for a few drivers but I'm working my way through those.

I've just uploaded DBD::ODBC 1.33 to CPAN.

This release contains no new changes since the 1.32_5 development release but is the official release for all the 1.32 dev series. The complete changes can be found below. The main thrust has been Unicode improvements.

The most significant enhancements are:

• unicode support for catalog/schema/table/column names in table_info and column_info
• now using SQLGetTypeInfoW on unicode builds
• new odbc_driver_complete attribute to allow interaction with ODBC dialogs on Windows.
  I'd really like to hear from anyone who uses this as I've had no feedback so far - just drop me an email if you have

and bug fixes:

• remove a debugging printf - sorry, most embarrassing.

In a rare moment (I hope) of stupidity last weekend when I was a little bored (bad cold stopped me doing what I really wanted to do) I looked through the DBD::ODBC TO_DO list and saw the "implement execute_array/execute_for_fetch" item which has been in that file for years. I know for sure implementing it will be a lot faster than using DBI's default methods (which effectively do a row at a time) mostly because I wrote an ODBC tutorial years ago showing how much faster binding arrays of parameters is (Easysoft ODBC-ODBC Bridge Performance White Paper) but I also knew it would be a PITA to write. The main problem is that DBD::ODBC has loads of workarounds for broken drivers and special cases.

I've uploaded the 4th development release of DBD::ODBC 1.32. This version improves Unicode support in metadata functions even further. My intention is to release this as a full version in the next week unless I get a load of bug reports. The changes since 1.31 are:

I have just uploaded 1.32_2 development release of DBD::ODBC. This contains one rather nice enhancement for Windows users which adds the new odbc_driver_complete attribute described as below. This allows DBD::ODBC on Windows to obtain a window handle which means if the ODBC Driver Manager or ODBC Driver needs to throw a dialogue to complete the data source or perhaps re-enter an expired password it can. Any testing will be greatly appreciated. The full changes since 1.31 are:

I maintian DBD::ODBC but I am wrestling with problems coping with 64 bit platforms. The problem is rather complex but I'm hoping that by describing it here someone will help come up with a logical answer to at least stop DBD::ODBC building in circumstances which are suspect.

I have just uploaded DBD::ODBC 1.31 to pause. This is the culmination of 7 development releases and I thought it was time to do an official release. Due to personal issues I am unlikely to be doing another update to DBD::ODBC in the near future but if you find issues please report them on RT and I'll try my best. The changes since 1.29 are below. There are significant changes since the last official release and a few changes in behaviour. If you didn't test a development release and it now goes wrong I'm sorry but after 7 development releases you had your chance.

I've just released DBD::ODBC 1.30_6 to CPAN. This is the culmination of 3 months of changes through 1.30_1 to 1.30_6 and also contains a few changes in behaviour (you are warned). It is unlikely that I will get much chance to do anything with DBD::ODBC for the next few months so I really need feedback before this becomes 1.31. Here is a list of changes since 1.29:

1. Changes in DBD::ODBC 1.30_6 June 4, 2011
[BUG FIXES]

A word of warning. The build process for DBD::ODBC against unixODBC on 64 bit platforms may not produce a workable solution perhaps even segfaulting. The short reason is that few Linux distributions/packages of unixODBC are up to date and few distribute unixODBC's odbc_config which DBD::ODBC needs to ascertain the compiler defines required to build a DBI driver which matches unixODBC. The long answer which which includes a workaround follows.

Some background: