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

Recently at $work I've been battling with some Perl code which retrieves data from Oracle via DBD::Oracle and a package function which returns a reference cursor. As I've mentioned before in this blog, the user has no select privilege on the database but can call package procedures/functions which return reference cursors and hence data from the database.

The query we have a problem with attempts to return multiple rows but one column is actually a list of primary keys from another table:

I've been using DBD::Oracle for a fairly major application here for some time. Most of the code is actually in Oracle procedures but some remaining code is in Perl. Since we upgraded to Oracle 11Gr2 DBD::Oracle's 26exex_array.t test has always failed. I've not been too bothered about this since we don't use the execute_array method (implemented in DBI for most drivers but implemented in DBD::Oracle directly). However, testing has unearthed some worrying results.

Just hit a rather annoying problem in DBD::Oracle 1.24a today. Our application contains all the logic in database procedures and in some cases database result-sets are returned to our Perl code via a reference cursor. Due to problems with ora_auto_lobs not working on reference cursors in previous DBD::Oracle releases we generally use Data Interface for Lob Locators where ora_lob_length returns a lobs sie and ora_lob_read is used to retrieve it.

I've reported Support binding of integers so they are returned as IVs at rt for DBD::Oracle.

It appears that DBD::Oracle restricts the RowCacheSize to 128, why? I know how much memory I can afford to use for retrieving rows better than DBD::Oracle and as far as I can see this could be set a lot higher.

Just spent a few hours trying to find out why the RowCacheSize attribute in DBD::Oracle does not seem to have any affect at all. The following code demonstrates the problem:

Spent some time today trying to work out why the system I am working on was displaying unicode strings in errors double utf-8 encoded. Looks like a bug in DBD::Oracle. I posted the following example to dbi-users list: