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:[EMAIL PROTECTED] Sent: Thursday, December 15, 2005 3:42 PM To: dbi-users@perl.org 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
