I devoted some time to try and reduce the massive DBD::Oracle rt list today. Some issues should be fixed now (see below) but in the mean time we have a number of stalled issues and some issues more than 1 year old and some more than 3 years old!
DBD::ODBC 1.36_2 is now on CPAN. I'm afraid this makes some incompatible changes with the last full release and for that I appologise. It seems I was just too ambitious defaulting the internal execute_for_fetch to on. I suspected some ODBC drivers would have bugs which prevented them from working but there are just too many actively used drivers for me to test them all and I hoped this would encourage fixes to them.
Yanick has just released a new development release of DBD::Oracle DBD-Oracle-1.43_00. As I mentioned in my blog a week or so ago, this release has a huge number of lines of code changed to remove the use of DBIS (see Changes to make DBIS more efficient and speeding up XS_DBI_dispatch()). This release removes the last few DBIS calls. As a result, if you are using a Perl built for threads (useithreads=define) this release is significantly faster than previous releases.
I've seen CPU usage nearly halved on fetches of large numbers of rows and I've had reports where people are doing lots of different selects for small numbers of rows of up to 10* quicker.
If you depend on DBD::Oracle you are strongly advised to try this version as this was over a 160K diff when I checked it in. If you notice anything broken please post an example to the dbi-users list.
A list of changes in this release is:
I have released DBD::ODBC 1.36-1 to cpan. With hindsight I was probably too ambitious releasing 1-35 with the default for execute_for_fetch enabled. This decision was based on a) my experience with writing bound arrays of parameters in the ODBC-ODBC Bridge b) I knew some drivers would have issues but I thought this might encourage fixes c) it is so much faster. As it turns out I am seeing issues currently with SQLite, Freetds, MS Access and even MS SQL Server.
Thanks to Dave Mitchell for finding this, see Changes to make DBIS more efficient and speeding up XS_DBI_dispatch(). If you are using a Perl built with thread support (useithreads=define) a number of DBDs use DBIS macros from DBI which are expensive in a threaded Perl and no longer neccessary. The threads referenced above have all the gory details.
This week I've attempted to remove all DBIS usage from DBD::Oracle and have managed in all but a couple of cases. If you upgrade to DBI 1.618 and get the latest DBD::Oracle from subversion trunk (see How to create a patch using Subversion you could see a pretty substantial speed up.
I've uploaded Perl DBD::ODBC 1.35 to CPAN.
This is the culmination of 7 development releases in the 1.34 chain and is a significant release containing a lot of changes and enhancements. As always I would like to thank everyone who has helped and especially CPAN testers. The full list of changes since the last official release is below.
My intention is to release this as 1.35 in the next week so if you find any issues please let me know soon.
=head2 Changes in DBD::ODBC 1.34_5 February 17 2012
* The 40UnicodeRoundTrip tests counts could be 1 off in some cases.
* Fix for t/03batt.t which could fail a test if the data source had
no table - Kenichi Ishigaki
* If a driver misbehaves during global destruction e.g. SQLFreeStmt
fails but no error is available DBD::ODBC issues an error saying
an error occurred but no error diagnostics could be found. This is
I've uploaded DBD::ODBC 1.34_4 to CPAN.
This release contains all changes/fixes/enhancements since 1.33 and also the new odbc_getdigarec and odbc_getdiagfield methods.
=head2 Changes in DBD::ODBC 1.34_4 February 5 2012
* When odbc_getdiag* methods were added they installed themselves
into DBI but did not set IMP_KEEP_ERR so calling them cleared
=head2 Changes in DBD::ODBC 1.34_3 February 3 2012
* Linking against unixODBC was working by accident on most UNIX
In the last few days we've suddenly started getting this error. The really weird thing is we get this when inserting data into a table! There was a trigger on the table we were inserting into so I disabled it but the problem did not go away. In fact it was easily reproducible with a simple insert into the "problem" table. Looking at the table in question it had around 500000 rows and included a clob but other than that nothing special. Since this is only a development system we deleted all the rows in the table and reenabled the trigger and the problem went away.
I've just bought a new Foxsat-HDR to replace a previous Foxsat-HD and more importantly free up my Digital Pioneer freeview PVR as we've just lost the analogue signal and my other Panasonic PVR/DVD player in another room is analogue.