RE: DBD ODBC question - $dbh->{odbc_exec_direct}
- From: jurlwin@xxxxxxxxxxxx (Jeff Urlwin)
- Date: Wed, 28 Dec 2005 00:44:34 -0500
Without looking at your code, I can guess:
Even if you only expect one row, you need to select until no more
results are returned, which triggers the finish() for you. If you
don't, you need finish().
Jeff
-----Original Message-----
From: Ryan Stille [mailto:rps@xxxxxxxxxxxxxxx]
Sent: Thursday, December 15, 2005 3:42 PM
To: dbi-users@xxxxxxxx
Subject: DBD ODBC question - $dbh->{odbc_exec_direct}
I am working on a script that inserts records into a Progress database.
The script connects via DBI and odbc.
As I loop through each potential record to import, I query the database
for some info. Occasionally I get errors like this:
DBD::ODBC::st execute failed: [OpenLink][ODBC][Progress Server]Stale
request handle. Request was not opened or has been closed. (1253)
(SQL-S1000)(DBD: st_execute/SQLExecute err=-1) at ./siimport.pl line
170.
DBD::ODBC::st fetchrow_array failed: (DBD: no select statement currently
executing err=-1) at ./siimport.pl line 171.
DBD::ODBC::st execute failed: [OpenLink][ODBC][Progress Server]Stale
request handle. Request was not opened or has been closed. (1253)
(SQL-S1000)(DBD: st_execute/SQLExecute err=-1) at ./siimport.pl line
170.
DBD::ODBC::st fetchrow_array failed: (DBD: no select statement currently
executing err=-1) at ./siimport.pl line 171.
DBD::ODBC::st execute failed: [OpenLink][ODBC][Progress Server]Stale
request handle. Request was not opened or has been closed. (1253)
(SQL-S1000)(DBD: st_execute/SQLExecute err=-1) at ./siimport.pl line
170.
DBD::ODBC::st fetchrow_array failed: (DBD: no select statement currently
executing err=-1) at ./siimport.pl line 171.
On some of the queries I was able to switch from:
$sth = $dbh->prepare($query);
$rc = $sth->execute();
($si_owner) = $sth->fetchrow_array();
To:
($si_owner) = $dbh->selectrow_array($query);
Which make the problem go away for some reason. I was not able to
change all the queries to use selectrow_array of course. But after
googling the "select statement currently executing" I came up with this:
$dbh->{odbc_exec_direct} = 1;
Which made the problem go away completely. But I'd really like to
understand why. I'd hate to see this problem come up again when I put
the script into production. The blurb from the documentation was no
help:
odbc_exec_direct -
Force DBD::ODBC to use SQLExecDirect instead of SQLPrepare() then
SQLExecute. There are drivers that only support SQLExecDirect and the
DBD::ODBC do() override doesn't allow returning result sets. Therefore,
the way to do this now is to set the attributed odbc_exec_direct. There
are currently two ways to get this: $dbh->prepare($sql, {
odbc_exec_direct => 1}); and $dbh->{odbc_exec_direct} = 1; When
$dbh->prepare() is called with the attribute "ExecDirect" set to a
non-zero value dbd_st_prepare do NOT call SQLPrepare, but set the sth
flag odbc_exec_direct to 1.
Thanks for any help.
-Ryan
.
- Prev by Date: Re: Building DBD::Oracle with the new Oracle Express product.
- Next by Date: RE: DBD-Sybase 1.07, FreeTDS 0.63, HPUX 11.11: Build problem (maketest)
- Previous by thread: RE: DBD ODBC question - $dbh->{odbc_exec_direct}
- Next by thread: RE: Bug in Oracle driver ?
- Index(es):
Relevant Pages
|
|