Blogs

Common problems calling procedures in MS SQL Server via DBD::ODBC

Recently I've had a spate of issues reported in dbi-users mailing list and direct to me wrt calling procedures in MS SQL Server. I thought it might be worth covering some of the more common ones here.

How to protect my laptop when it is stolen

I've had a laptop stolen! It was a long time ago, I'd paid thousands for it (over £3000, it was a long time ago when laptops were a lot more expensive than now) and I was gutted. To make matters worse I'd not put a BIOS password on it and also this is when I discovered my mis-sold insurance policy only covered £1200. Thank you Skipton Building Society - not. I took it in to work to show a colleague Linux on it and made the mistake of leaving it in my bosses car whilst we went for a drink before going home. Someone got in to the underground car park, broke the window and made off with it - thief - sorry for your window boss. If I'd installed a BIOS password then at least I would have had the small comfort that although not impossible to get around, it would have made matters difficult.

New 0.19 release of DBIx::Log4perl

Recently I updated DBIx::Log4perl to handle DBI's clone method. This proved a little troublesome as clone is marked as "likely to change" and I'm not sure any other DBIx's have added clone. The problem I had was that clone does not call connect and all the code I had to add DBIX::Log4perl's attributes into the dbh was in connect.

DBD::ODBC and date/time/datetime/timestamp

Over the last few months I've been receiving an increasing number of emails from people experiencing problems inserting date/time/datetime/timestamp values into MS SQL Server specifically although not exclusively. There are a number of MS SQL Server ODBC drivers but the ones I see the most (in no particular order) are a) MS SQL Server ODBC Driver b) MS SQL Server Native Client driver c) Easysoft's SQL Server ODBC Driver and d) freeTDS. I hope to write a more expansive tutorial on this in the near future but until then I hope this blog post will help.

New release (0.18) of DBIx::Log4perl

Yesterday I released DBIx::Log4perl 0.18 This principally add supports for DBI's clone method and fixes fetchrow_array ignoring calling context. It also adds a few speedups spotted using Devel::NYTProf, adds logging of connection attributes and fixes a few more minor issues.

DBD::ODBC 1.23_2 released

Today I released a new development version of DBD::ODBC (1.23_2).

Apologies to the few people waiting on changes but I've been snowed under with work on DBIx::Log4perl, DBI and DBD::Oracle but mostly my day job (which uses all of these modules and a alot more).

Forking after DBI connection, clone and subclassing DBI

It all started when a daemon I am developing hit a job which took too long to run and so it ignored any connecting clients whilst running the job. A long term plan exists to sort this out but it is getting in the way of some test code so I decided to write a small workaround until I am ready to implement the full solution. The workaround seemed so simple I thought it would only take half an hour to do - how wrong I was.

Tired of bugs in Microsoft's SQL Server native client ODBC Driver

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

Caught by a 5 and half year old Perl bug

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.

Spent way too long finding bug in Pod::Simple::HTMLBatch today

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.
Syndicate content