I've written commercial software and I maintain some open source software. I've also helped out with software support in various companies when the support person escalated the support issue to a developer. In the Open Source arena I think I've provided good support for the software I maintain and the company I work for now provides exceedingly quick support which more than often sorts the problem out immediately. All this is done by looking at the problem and provided information and providing a custom response but as far as I can see a descreasing number of companies manage to do this.
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
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 just bought a Pro 100M Wireless Shutter Remote Control Release fits Nikon D90, D3100, D5000, D7000 Digital Cameras from Amazon supplied by BV-electronics for £13.99 delivered.
I have a Nikon D3100.
Ordered Sunday night and arrived Wednesday morning.
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.
I've just bought an eTRV from Chalmor for £59.99. There are much cheaper electronic TRVs but the reviews on screwfix slated them for noise, low battery life, losing settings when battery fails and other faults.
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:
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).
I got my Raspberry Pi a week ago and wrote up my first impressions about the RP and whether it would work to get our children programming at Raspberry Pi - will it get our children programming? and if so why not in Perl?.