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 recently stepped up from a bridge camera (a Panasonic Lumix) to a Nikon D3100 DSLR. I like the camera in general but one issue is bothering me a lot and it is the exposure metering and a too dark warning.
Like many people I've used the Perl module Data::Dumper for years and been reasonably happy with the output. Generally I want the output rolled up into the smallest (line-wise) output and Data::Dumper allows this. However, I use Math::FixedPrecision quite a bit in this project and as it is a blessed object the fixed precision numbers of 2 come out ridiculously verbose and almost unreadable.
I've been using Perl on and off for over 15 years. In the last 10 years of so I've been using Perl a lot in my work and play. I don't have a huge list of modules I look after but I maintain a couple of modules and contribute to many. What never ceases to amaze me is the Perl community. By that I mean the huge group of people working tirelessly to improve the Perl core, write Perl modules and applications, organise conferences and workshops, test Perl and CPAN, report issues, support Perl on IRC, the many mailing lists and web sites and give freely their knowledge and expertise to others. Thank you.
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.
I've just uploaded DBD::ODBC 1.30_1 to CPAN.
If you use Windows or a Unicode build of DBD::ODBC on non-Windows platforms you should really test this release as it contains a change in behaviour for Unicode. This release also contains a small but perhaps significant change to the silent rolling back of a transactions when disconnect was called when AutoCommit was disabled. The complete changes since 1.29 are below. Again, many thanks to all the people RTing issues and providing feedback/testing.
This all started with a stackoverflow question at Automatic character encoding handling in Perl / DBI / DBD::ODBC. It then led to DBD::ODBC doesn't handle windows-1252 characters and lastly a small discussion on dbi-dev at Decoding data from the database in DBD.