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.
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.
Today I released a new development version of DBD::ODBC (1.23_2).
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.
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.