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

I spent a small amount of time debugging a problem in a script I was modifying this morning as a while loop with each seemed to loop forever:

I've just uploaded DBD::ODBC 1.44_1 to the CPAN. This is the first release since the enforced move away from subversion on perl.org (not that this is a complaint). Hopefully, with DBD::ODBC being on github now I might get a bit more in the way of contributions.

There are a couple of bugs fixed but unless you reported them I'd be surprised if you are affected by them but all testing is welcome.

• Changes in DBD::ODBC 1.43 March 6 2013

This is a full release of all the 1.42_* development releases.

plus:

• [Bug FIXES]

Minor fix to 10handler.t test suite which relied on a native error being true instead of defined.

• Changes in DBD::ODBC 1.42_5 January 25 2013
• [BUG FIXES]

Not all modules used in test code were specified in build_requires.

• Changes in DBD::ODBC 1.42_4 January 21 2013
• [ENHANCEMENTS]

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.

Whilst at YAPC::EU 2012 (what a great conference BTW) a friend suggested I might change DBIx::Log4perl to DBIx::LogAny (where Log::Any did not exist when I wrote DBIx::Log4perl). DBIx::Log4perl came about when I was writing a large DBI based application and needed to know what was going on and realized the DBI tracing was far too detailed for us. DBIx::Log4perl logs at different levels DBI method calls and in particular everything it can find when an error occurs. Mostly all I needed was everything I could find when an error occurred but logging SQL passed to do and prepare and bound parameters etc was useful too.

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

[BUG FIXES]

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

Whilst at YAPC::EU 2012 there was a talk which included Log::Any. I didn't attend that talk but a friend (Jens Rehsack) was and he wondered why DBIx::Log4perl wasn't DBIx::LogAny. The simple answer is that Log::Any did not exist when I wrote it and we were using Log::Log4perl.

I had plans for today but the weather was poor and so I thought I'd try a quick hack of DBIx::LogAny. You can find it here. There are 2 problems:

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).