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
