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
.

Relevant Pages

  • Re: notice and warning
    ... You expect some piece of data from a post in your script, ... So you use $_REQUEST["userid"] which works perfectly fine as long as you get the userid in via POST. ... Now you find yourself in the situation that when you call this script for any reason without the POST info, you will delete yourself if you prefer $_REQUEST over $_POST. ... Saying that using $_REQUEST 'scales better' is utter nonsense. ...
    (comp.lang.php)
  • Re: notice and warning
    ... You expect some piece of data from a post in your script, ... prefer $_REQUEST over $_POST. ... the different meanings the input should have based on how it arrives. ... that's bad design. ...
    (comp.lang.php)
  • Re: notice and warning
    ... You expect some piece of data from a post in your script, eg: userid. ... prefer $_REQUEST over $_POST. ... in this instance, it scales more 'easily'. ...
    (comp.lang.php)
  • Re: Reading remote Session ID
    ... i use a pink wand, just like your blue wand, but pink. ... Perhaps you can just make it harder for the script by ... require that the IP that makes the request for the page be the same ...
    (alt.php)
  • Re: [PHP] How does the Zend engine behave?
    ... include files compiled when the script is first compiled, ... Now suppose a second request ... PHP script to be executed. ... not actually the PHP tokenization. ...
    (php.general)