On Tue, Oct 15, 2002 at 04:50:35PM -0700, Scott wrote:
> When I use DBD::Oracle 1.12 with DBI 1.30 (I also saw this on
> 1.06/1.15) I see two parse_calls for every execute on all selects.
> Update/insert/delete just have 1 parse/execute. I have a simple test
> script.
>
> #!/usr/local/bin/perl -w
>
> use strict;
> use DBI;
>
> my $dbh = DBI->connect("dbi:Oracle:db", "user/pass");
> $dbh->trace(8);
> my $sth = $dbh->prepare("SELECT 1 FROM dual");
Try:
my $sth = $dbh->prepare("SELECT 1 FROM dual", { ora_check_sql => 0 });
> Each time I run the script, the parse goes up by two and the
> executions by one. If I put a sleep before the execute, I can see that
> prepare is doing one parse, and execute is doing both a parse and an
> execute. I also tried just doing a selectall_arrayref and it also has
> two parses. Any ideas why the extra parse?
The prepare() method 'describes' the statement, triggering a parse.
I believe the parse at execute time is fundamentally an Oracle bug
(and/or isn't a "full" parse). I'd be grateful if someone could ask
Oracle support about that.
Meanwhile, ora_check_sql => 0 disables the parse-at-prepare.
But there are down-sides to ora_check_sql=0 - it was the default
for a little while. Here's an old message that, although being out of
date in various ways, describes some of the issues:
http://www.bitmechanic.com/mail-archives/dbi-users/Apr1999/0538.html
(at the time ora_check_sql=0 was the default)
In principle I don't have a fundamental objection to defering the
'describe' until execute and thus defering detection of syntax
errors until the execute. I'd probably add a new $dbh attribute to
set the desired default behaviour so you don't have to add it to
each prepare() call.
Tim.
