The Perl programming language

Perl Programming: What I didn't know about 'each'

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:

use strict;
use warnings;
use Data::Dumper;

my %x = (one => 1, two => 2, three => 3, four => 4);

while (my ($key, $value) = each %x) {
    # obviously the real script was doing a lot more here
    print "$key $value\n";
    print Dumper(%x); # or simply my %y = %x

Perl DBD::ODBC 1.44_1 released to the CPAN

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

Perl DBD::ODBC 1.43 released to the CPAN

  • Changes in DBD::ODBC 1.43 March 6 2013
  • This is a full release of all the 1.42_* development releases.


    • [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

New 1.42_2 release of Perl DBD::ODBC

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.

Perl DBIx::LogAny might replace DBIx::Log4Perl

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.

Perl DBD::ODBC 1.42_0 release

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

Perl DBIx::LogAny replacement for DBIx::Log4perl

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:

Perl DBD::ODBC 1.40_3 released to the CPAN

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.

Inserting unicode characters > 0xFFFF (surrogate pairs) into MS SQL Server with Perl DBD::ODBC

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:


New Perl DBD::ODBC development update - important changes, please test

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

Syndicate content