New experimental DBD::ODBC 1.26_1 release

I've just uploaded a new experimental (and development) release of 
DBD::ODBC 1.26_1 to CPAN. This contains over 200 block code changes so 
it is a VERY significant change and should not be used on production 
servers until you have tested it.

This release adds little in the way of functionality (and a few bug 
fixes) but is a major push to get DBD::ODBC truely ODBC 3.0 compliant 
and as such it will REQUIRE an ODBC driver manager to translate ODBC 3.0 
calls to ODBC 2.0 if you are unlucky enough to have an ODBC 2.0 driver.

I include the changes below but a few notes in addition:

1. If you are using (or more likely attempting to use) the mdbtools ODBC 
driver then you are out of luck. I have no issues with anyone working on 
mdbtools personally but it is so far from being a reliable ODBC driver I 
cannot accept bug reports for DBD::ODBC involving it. I started adding 
workarounds and the list got just too big, sorry. There are alternatives 
to mdbtools but they will cost you hard cash; I'm afraid that is the way 
it is right now.

2.  I don't think anyone has been using DBD::ODBC without an ODBC driver 
manager in the last few years but I could be proved wrong. If you are, 
again, sorry but what is the problem with you using one (in the future I 
will remove support for linking directly with an ODBC driver and require 
an ODBC Driver Manager but that will come later in the DBD::ODBC 1.26 
release chain). If you are still not using an ODBC driver manager this 
article (http://www.easysoft.com/developer/interfaces/odbc/linux.html) 
might persuade you to start using one (and in particular 
http://www.easysoft.com/developer/interfaces/odbc/linux.html#odbc_driver_managers). 
Basically, an ODBC Driver Manager will map ODBC 3 calls to an ODBC 2 
driver and vice versa and it avoids a load of nastiness in DBD::ODBC 
which is best employed in the driver manager. I recommend the unixODBC 
Driver Manager and my reasons are fairly straight forward 1) it is open 
source 2) it is included with most Linux distributions 3) the main 
developer works in my office so it is easy for me to liase with him and 
get problems fixed 4) it is the most complete non Microsoft Driver 
Manager implementation 5) it supports unicode like MS does, 6) the 
cursor library works to the ODBC spec... I'm sure there is more. 
However, if you choose to use iODBC (another ODBC Driver Manager) that 
is fine and I will continue to support it. There are a few other more 
minor non-Microsoft ODBC Driver Managers but they don't support Unicode 
like the MS one so they provide a big headache for me and unless anyone 
else wants to take over support for them they are problematic.

3. You will need a more up to date DBI (v1.609 to be precise) to use 
this version of DBD::ODBC. I'm sorry about this but the reasons are 
explained in the DBD::ODBC Changes file and the links from it.

4. I should point out (if you didn't know) I work for Easysoft which 
provides a number of commercial ODBC Drivers for Windows and UNIX and 
supports the development of the unixODBC Driver Manager. This is not why 
I recommend unixODBC (it is purley a recommentation on what I believe is 
the best) and I assure you that as far as DBD::ODBC is concerned my 
focus is on making DBD::ODBC better but I of course have loyalties with 
the company who pays me my salary. If anyone has a problem with that I 
will happily give up maintainership of DBD::ODBC to someone else 
considered more neutral.

The changes follow:

=head2 Changes in DBD::ODBC  1.26_1 October 24, 2010

   There are over 200 block changes in the source code for this release
   from the previous one (see below). If you are using DBD::ODBC in
   production you should not upgrade without testing this release first
   as it introduces a lot of internal changes. DBD::ODBC has now gone
   entirely ODBC 3 and relies on an ODBC Driver Manager to map calls
   to ODBC 2.0 drivers (why are you still using ODBC 2.0 drivers?).
   From now on DBD::ODBC needs to be linked with an ODBC Driver Manager
   and I recommend unixODBC on UNIX and the MS ODBC Driver Manager
   on Windows. There are really good reasons for this but mainly it
   is because an ODBC Driver Manager will map ODBC 2.0 calls to an
   ODBC 3.0 driver and vice versa and handle UNICODE transparently.

   Bumped Test::Simple requirement up to 0.90 so we can use done_testing
   and note.

   Bump Perl requirement to 5.8 as per DBI.

   Workaround a bug in mdbtools which fails to set the out connection
   string in a SQLDriverConnect call. This can lead to:

   Fixed panic: sv_setpvn called with negative strlen at
   blib/lib/DBD/ODBC.pm line 107.

   Added rt_61370.t for rt 61370.

   Removed last remaining sprintf calls and replaced with my_snprintf.

   Changed the point at which DBD::ODBC switches from VARCHAR to
   LONGVARCHAR or WVARCHAR to WLONGVARCHAR when SQLDesribeParam fails. It
   was 4000 and is now 2000 for unicode builds.  Works around a daft issue
   in the MS SQL Server driver which will not allow 'x' x 2001 converted to
   wide characters to be inserted into a varchar(8000).

   Minor change to Makefile.PL to print out found libs for iODBC and
   unixODBC.

   Added some FAQs for problems with iODBC and a recent bug in DBI.

   Added FAQ on my_snprintf problem.

   Fixed some pod errors in FAQ document.

   Fixed warning on 64 bit Strawberry Perl when compiling dbdimp.c for
   cast from ptr to UDWORD.

   Moved to_do items from Changes to TO_DO.

   Reformatted this file to save Jens work.

   Changed calls to SQLTransact (ODBC 2.0) to SQLEndTran (ODBC 3.0).
   There really shouldn't be any ODBC 2.0 drivers still around but even
   if there are, the ODBC driver manager should do the mapping for us.

   Changed calls to SQLGetConnectOption/SQLSetConnectOption to
   to SQLGetConnectAttr/SQLSetConnectAttr for ODBC 3.0.

   Changed calls to SQLColAttributes (ODBC 2.0) to SQLColAttribute
   (ODBC 3.0).

   Bumped requirement on DBI to 1.609 because that is the first version
   to contain a dbipport.h which defined my_snprintf - see
   https://rt.cpan.org/Public/Bug/Display.html?id=62346 and
   http://www.nntp.perl.org/group/perl.dbi.dev/2010/10/msg6335.html

   Various small changes to dbdimp.c which should have no effect other
   than to make it leaner:

     Removed all dTHR occurrences from dbdimp.c as it is a NOOP since 5.8
      and we need 5.8 at least.
     Removed dbd_param_err as it was not used
     Removed odbc_get_query_timeout as it was never compiled
     Removed eod field from statement as it was never used
     Removed a load of commented out code
     Replaced some SvPV calls with SvPV_nolen when we didn't used the
       length
     Removed some silly code from dbd_db_execdirect which attempted to
       return -3 - don't think it could ever get run.
     Minor tracing output tidy up
     Removed dbd_caution as it was no used
     Localised more variable declarations

Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com