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

Yet more time today spent tracking down another bug in Microsoft's SQL Server native client ODBC driver reported in RT for DBD::ODBC.

Perl can be a lot of fun and it can mean tearing your hair out; not that I'm suggesting other languages aren't the same. For the second time in a week I've been caught out by a nasty bug but after an hour or so of investigation imagine my surprise to see it appears to be a 5 and half year old Perl bug.

We moved our development platform to a new Ubuntu 9.10 machine yesterday. One of the things I like about Perl is being able to specify dependencies so in a single Makefile.PL for our application we list 50 or so modules and their versions. All we need to do to get our Ubuntu box loaded with the "right" Perl modules is untar our applications package and run "cpan ." and magically all our dependencies are sorted out and installed; this probably leads to hundreds of modules being installed. On the down side, cpan installs the latest and greatest (or not) or each module and here is where our problem with Pod::Simple::HTMLBatch started.

A search for the simple string perl on google today resulted in most of the sites you'd expect to see. However, I notice that at least here in the UK, the 5th entry is perl.co.uk. What is perl.co.uk?

I released a new development release of DBD::ODBC the other day. Here is an extract from the change log:

Noel Burton-Krahn posted a patch for UTF-8 encoded data in Aster (based on Postgres) today. This prompted me to complete a number of small changes I had in the fire and incorporate his changes.

I've got a little behind in the work that has been gathering for DBD::ODBC lately so a few days ago I rt'ed a list of jobs in the hope that would stir me into action.

If you are using cygwin and unixODBC I'd like to know. I am about to make a change to DBD::ODBC which might stop it detecting unixODBC under cygwin so would appreciate talking to anyone who uses this configuration.

As anyone who reads my blog knows we've been profiling a large amount of Perl code recently. A daemon process receives jobs to run and in most cases (a few are run immediately) places them on a queue in the database. For a queued job we are really interested in the turnaround time i.e., the time from seeing an incoming request, decoding it (it is in JSON), checking it, inserting the request into the database and returning a unique job ID; obviously this determines how quickly we can queue jobs.

It is often said don't optimize too early. I try very hard to keep to that, and I do mean very hard. In the project I am working on now we have a basically working implementation (although some functionality is still to code, it is on the edges - this probably counts as too early - oh dear). We have a rather complicated setup which I don't have the time to go into here but at its simplest it is the age old client-server relationship and involves a lot of database (Oracle via DBD::Oracle) access. The client in this case is really a daemon process receiving work to process and either processing it or passing it on to another server to be queued and worked on later.