Curious. Scott, what is your NLS_LANG and what is the character set (SELECT * FROM V$NLS_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET')?
Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA > -----Original Message----- > From: Mark Dedlow [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 16, 2002 11:45 AM > To: Tim Bunce; Scott > Cc: [EMAIL PROTECTED] > Subject: RE: Two Oracle parse calls for each execute > > > Scott, > > Something about your setup. Don't know what. Here's what I get > on Oracle 8.1.7.1. > > $c = $dbh->prepare('select 1 from dual', { ora_check_sql => 0}); > > for (1..10) { $c->execute } > > SQL>select parse_calls, EXECUTIONS from v$sqlarea where > SQL_TEXT = 'select 1 > from dual' > > PARSE_CALLS EXECUTIONS > ----------- ---------- > 1 10 > > Mark > > > > -----Original Message----- > > From: Tim Bunce [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, October 16, 2002 3:51 AM > > To: Scott > > Cc: [EMAIL PROTECTED] > > Subject: Re: Two Oracle parse calls for each execute > > > > > > 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. > > >
