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

New rt for DBD::ODBC at DBD::ODBC - [Microsoft][SQL Server Native Client 10.0][SQL Server]The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. The SQL Server native client driver has proved to be a bit buggy and this /may/ be another one - we'll have to wait and see. DBD::ODBC already has a number of workarounds for issues in the MS SQL Server ODBC Driver and Native Client Driver.

Yesterday I was contacted by someone at Ingres with a patch to make DBD::ODBC support the ingresCLI driver manager. I'm always happy to accept these patches and with a moderate rewrite (necessitated by the fact I'd hacked Makefile.PL around a lot recently for 64bit support without checking it in) I managed to rewrite the patch. The changes are checked in to subversion now and are reported to work for Ingres. Unicode support is not there yet but I believe they are working on it.

I've been working on 1.22 doesn't compile on 64 bit systems with unixODBC on and off for a few days. Boy, this is tiresome (no reflection on the poster of this rt).

Today a long standing Easysoft customer upgraded from DBD::ODBC 1.13 to 1.21 and their scripts stopped working properly :-( It appears they use the ping method to detect whether the connection handle is connected to the database and since upgrading to 1.21 they are getting DBD::ODBC::db ping failed: Cannot allocate statement when disconnected from the database at ./xxx.pl line 11 when calling the ping method after a disconnect.

I have released 1.22 of DBD::ODBC to CPAN today. This includes a fix to a serious problem with a unicode-enabled DBD::ODBC (the default on Windows) and the transfer of character fields between the database and Perl of greater than 64K characters. If this affects you then you should upgrade immediately. See the announcement on the dbi-users/dbi-dev or dbi-announce lists. This release also fixes a problem with inserting NULL into nvarchar fields in a unicode-enabled DBD::ODBC.

Fixed bug referred to in rt 46597 reported by taioba and identified by Tim Bunce. In Calls to bind_param for a given statement handle if you specify a SQL type to bind as this should be "sticky" for that parameter. That means if you do: $sth->bind_param(1, $param, DBI::SQL_LONGVARCHAR) and follow it up with execute calls that also specify the parameter: $sth->execute("a param"); then the parameter should stick with the SQL_LONGVARCHAR type and not revert to the default parameter type. The DBI docs (in subversion now)

I frequent perl monks a bit and late yesterday an issue came in with DBD::ODBC and Microsoft Access. The perl monks node and rt 46597 detail it all quite well. It appears DBD::ODBC was not following the DBI specification (as it was originally written) to the letter with respect to sticky bound parameter types but since then Tim Bunce has modified the DBI pod slightly to allow DBDs to enable a bound parameter to be rebound with a different type. The change to DBD::ODBC was fairly small but by the time I'd added a test case, bumped the version to 1.21_1 and tested a dozen or so ODBC drivers this consumed a fair amount of time.

I have released 1.21 of DBD::ODBC to CPAN. You can find a list of changes here.

I have released 1.19 of DBD::ODBC to CPAN.

You can find a list of changes here.