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

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).

Bugs in the MS SQL Server ODBC Driver (like this one) are still causing me a lot of grief. Basically, there are two main problems at the moment causing problems a) the MS SQL Server ODBC driver failing to return successfully from SQLDescribeParam or returning successfully with the wrong answer and b) xVARCHAR(MAX) columns (another Microsoft-specific column type).

This development release overcomes (a) at a cost by introducing odbc_force_bind_type which will cause DBD::ODBC to omit calling SQLDescribeParam and simply use the type you set for binding parameters. Some will undoubtedly say, it used to be that way in the past, but if ODBC drivers could be relied on to have a working SQLDescribeParam then problems like (b) and unicode columns/data would be so much easier to work with. I've begrudgingly added odbc_force_bind_type as I'd rather ODBC Driver writers fix their bugs and the alternative is to add {TYPE => type} to DBI bind_param calls but so many people seem to work with multiple databases and don't want to have database specific attributes. However, the cost if you use odbc_force_bind_type comes in when you are mixing unicode and non-unicode data as for the problematic SQL where the driver's SQLDescribeParam fails or returns the wrong result you will have to resort to adding the TYPE attribute anyway.

So, I've bowed to the few that complained but will wait to see how this goes and hence a development release. As an aside, if anyone using DBD::ODBC for real was prepared to test DBD::ODBC pre-release I'd love to hear from you as very few CPAN smokers have a database set up and most of the tests are skipped.

The nitty gritty details of the changes since 1.23 can be found here.