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

I've heard people mention travis-ci but not really paid much attention to it, that is, until yesterday when I issued a pull request from my github account for a few minor fixes to DBI. I wondered if my pull request was applied and took a quick look at DBI on github to see my pull request was still pending. Clicking on my pull request I see a "All is well — The Travis CI build passed" and just clicked on it.

After being forced to drop the subversion repository used by DBD::ODBC as perl.org has dropped subversion I moved it to github. Then, my friends working on DBI related modules setup up perl5-dbi and Merijn (Tux) helpfully moved DBD::ODBC under that umbrealla for me - thanks Tux.

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.