connecting()?
Fellow DBIers, I was just discussing writing a callback on connect() to change authentication (my correspondent wants to use realm files). But then I discovered to my disappointment that there is no support for callbacks on connect(). This makes sense, frankly, since the method is called before the callbacks are applied, and callbacks execute before the method, not afterward (at least for now). But I've found great use by adding callbacks on connected(), so that they execute just after a connection. So I was wondering how folks felt about the idea of adding a connecting() method that executes just before the DBI tries to connect to the database? I think this would be a nice complement to connecting(), and instantly make a simple interface for adding a pre-connection callback, too. Thoughts? Best, David
DBD::Oracle 11gr2 ORA-38909
We have run into an issue with array processing in 11g. The developer was using execute_array and his sql statement had 'LOG ERRORS' in it. This did not error out until we switched to 11g. The issue is that only one is allowed, either 'LOG ERRORS' or 'SAVE EXCEPTIONS'. Our DBA logged and error report with Oracle and after several posts back and forth this is what they concluded, == After investigation and discussion, development has closed the bug as 'Not a Bug' with the following reason: this is an expected behavior in 11g and the user needs to specify either of 'SAVE EXCEPTIONS' clause or the 'DML error logging', but NOT both together. The batch error mode, in the context of this bug, is basically referring to the SAVE EXCEPTIONS clause. It seems the code is trying to use both dml error logging and batch error handling for the same insert. In that case, this is not a bug. For INSERT, the data errors are logged in an error logging table (when the dml error logging feature is used) or returned in batch error handles (when using batch mode). Since the error messages are available to the user in either case, there is no need to both log the error in the error logging table and return the errors in batch error handles, and we require the user to specify one option or the other but not both in 11G. Both features exist in 10.x. For 11.x, users should change their application to avoid the error. == So basically we need a way to turn off the 'SAVE EXCEPTIONS' for the batch mode. I found in dbdimp.c that the oci_mode is being set to OCI_BATCH_ERRORS in the ora_st_execute_array function. I was planning on setting it to OCI_BATCH_MODE and running a test to see if this will not error out. I report back when I have run the test, but I was wondering what would be the best way to give the user the ability to override the oci_mode. An attribute in the prepare method? Thanks, Scott
Re: connecting()?
On Wed, 31 Mar 2010 10:14:04 -0700, David E. Wheeler
da...@kineticode.com wrote:
Fellow DBIers,
I was just discussing writing a callback on connect () to change
authentication (my correspondent wants to use realm files). But then I
discovered to my disappointment that there is no support for callbacks
on connect (). This makes sense, frankly, since the method is called
before the callbacks are applied, and callbacks execute before the
method, not afterward (at least for now).
But I've found great use by adding callbacks on connected (), so that
they execute just after a connection. So I was wondering how folks
felt about the idea of adding a connecting () method that executes just
before the DBI tries to connect to the database? I think this would be
a nice complement to connecting (), and instantly make a simple
interface for adding a pre-connection callback, too.
Thoughts?
All in favour, if not only to be able to use $ENV{DBD_VERBOSE} and
$ENV{DBI_VERBOSE} to set verbosity on connection before it even starts!
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Comments on this patch for dbms_output_get() ?
I created this patch because of this issue (which we have run into),
==
Parameter Description
lineReturns a single line of buffered information,
excluding a final newline character. You should
declare the actual for this parameter as VARCHAR2 (32767)
to avoid the risk of ORA-06502: PL/SQL: numeric or value
error:
character string buffer too small.
status If the call completes successfully, then the status returns as
0.
If there are no more lines in the buffer, then the status is 1.
==
--- Oracle.pm.orig 2010-03-31 15:27:16.0 -0500
+++ Oracle.pm 2010-03-31 16:09:37.0 -0500
@@ -766,8 +766,11 @@
my $sth = $dbh-prepare_cached(begin
dbms_output.get_line(:l, :s); end;)
or return;
my ($line, $status, @lines);
+ my $version = join ., @{ ora_server_version($dbh) }[0..1];
+ my $len = $version = 10.2 ? 32767 : 400;
+
# line can be greater that 255 (e.g. 7 byte date is expanded on
output)
- $sth-bind_param_inout(':l', \$line, 400, { ora_type = 1 });
+ $sth-bind_param_inout(':l', \$line, $len, { ora_type = 1 });
$sth-bind_param_inout(':s', \$status, 20, { ora_type = 1 });
if (!wantarray) {
$sth-execute or return undef;
Thanks,
Scott
