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.
I've uploaded Perl DBD::ODBC 1.35 to CPAN.
This is the culmination of 7 development releases in the 1.34 chain and is a significant release containing a lot of changes and enhancements. As always I would like to thank everyone who has helped and especially CPAN testers. The full list of changes since the last official release is below.
My intention is to release this as 1.35 in the next week so if you find any issues please let me know soon.
=head2 Changes in DBD::ODBC 1.34_5 February 17 2012
* The 40UnicodeRoundTrip tests counts could be 1 off in some cases.
* Fix for t/03batt.t which could fail a test if the data source had
no table - Kenichi Ishigaki
* If a driver misbehaves during global destruction e.g. SQLFreeStmt
fails but no error is available DBD::ODBC issues an error saying
an error occurred but no error diagnostics could be found. This is