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.
An official release of the 1.28 development releases.
I'm about to release DBD::ODBC 1.29 after 4 development releases. Unfortunately, (as is often the case) I've found a bug just after the last development release related to batching of SQL statements and odbc_more_results. I'm fairly confident in it but if you use DBD::ODBC I'd love you to test it before I release it as it may be a while before I can release a new version.
You can find it here
I came across someone asking about DBIx::ProcedureCall today on Perl Monks in Execute Oracle Stored procedure using DBIx::ProcedureCall. Years ago I remember finding DBIx::ProcedureCall when we were about to embark on writing an application that used stored procedures in DB2, Oracle and MySQL. DBIx::ProcedureCall did not support DB2 and MySQL then and I was not that happy about the way it creates symbols in Perl for database procedures/functions so I dismissed it and I wrote my own code. When I saw it again on Perl Monks I thought I'd take another look at it and was surprised the supported DBDs has not increased (it is still Oracle and Postgres).
Firstly, I should say I don't use Windows that much these days. The Windows machines where I test DBI and DBD::ODBC I set up ages ago with a Perl built with MS Developer Studio and I tend to keep them for that purpose. However, I bought a whole load of nice shiny new parts to build myself a new PC a month ago and installed Ubuntu and Windows as I thought I could get a more up to date Perl on Windows at home.