Changes in DBD::ODBC 1.42_2 December 17 2012
There is no need to upgrade to this version unless you are on a 64 bit platform where ints are 4 bytes and you update/delete/insert more than 2^31 rows and need the affected rows back.
I've just released Perl DBD::ODBC 1.42_0 development release.
There is no reason to upgrade unless you are using the MS Access ODBC Driver.
=head2 Changes in DBD::ODBC 1.42_0 November 28 2012
MS Access requires a longchar column to be bound using SQL_LONGVARCHAR.
However, MS Access does not support SQLDescribeParam and we default to
SQL_VARCHAR in this case. The point at which we switch to SQL_LONGVARCHAR
was defaulted to 4000 (for MS SQL Server). We now default to SQL_LONGVARCHAR
for MS Access when data is > 255. This means you can remove those
I've just uploaded the DBD::ODBC 1.40_3 development release to the CPAN. If all goes well this will be the official 1.41 release in a weeks time.
Until recently it has been difficult to insert unicode characters above 0xFFFF into MS SQL Server. DBD::ODBC could do it in such a way that you can select them back correctly but the built in functions (like length, sorting and upper/lower etc) did not treat the surrogate pairs as such so it was limited.
Microsoft SQL Server 2012 introduces a new collation suffix (_SC) and it supports surrogate pairs (although there is an indication that the UTF-16 encoded data must be sent little endian and I've not managed to test on a big endian machine as yet). Here is some test code:
I have released a new development release of Perl DBD::ODBC. This contains some important bug fixes and changes so I strongly advise you to test this out.
There was a problem introduced in the test suite in 1.40_2 when run to non MS SQL Server which results in a few tests failing because done_testing is called twice (please ignore this - it is fixed in subversion trunk).
I got my Raspberry Pi a week ago and wrote up my first impressions about the RP and whether it would work to get our children programming at Raspberry Pi - will it get our children programming? and if so why not in Perl?.
I've just sent to the CPAN the 1.39 release of DBD::ODBC. This contains some bug fixes, one major enhancement to support TAF and one change in behaviour you should note.
Mostly due to the thread in dbi-dev at DBD::ODBC fetch is returning string for integer (unfortunately some of it was off list) and further comments and rt at Changes in binding columns in DBD::ODBC and DiscardString with SQL_INTEGER not working properly I have made significant changes to the binding of columns in a result-set for DBD::ODBC.
DBD::ODBC 1.36_2 is now on CPAN. I'm afraid this makes some incompatible changes with the last full release and for that I appologise. It seems I was just too ambitious defaulting the internal execute_for_fetch to on. I suspected some ODBC drivers would have bugs which prevented them from working but there are just too many actively used drivers for me to test them all and I hoped this would encourage fixes to them.
I have released DBD::ODBC 1.36-1 to cpan. With hindsight I was probably too ambitious releasing 1-35 with the default for execute_for_fetch enabled. This decision was based on a) my experience with writing bound arrays of parameters in the ODBC-ODBC Bridge b) I knew some drivers would have issues but I thought this might encourage fixes c) it is so much faster. As it turns out I am seeing issues currently with SQLite, Freetds, MS Access and even MS SQL Server.