Subject Re: [firebird-support] Prepared statement with transactions leads to a crash in gds32.dll
Author Helen Borrie
At 11:15 AM 2/11/2006, you wrote:
>Hi All,
>The following code snippet (php, sorry)
>causes a crash in gds32.dll whenever I have
>a lock-conflict. Debugger is saying that
>the crash is an Access Violation inside
>If I run this code from 1 client, everything
>works, if I run 2, I get a crash every time.
>I am using:
>Apache 2.0.54
>PHP 5.1.6 (CGI)
>Windows XP Pro
>Firebird 1.5.3
>It works fine if I do NOT use prepared statements.
>It works fine if I do not use explicit transaction handling,
>but very slow...
>I think that I am doing something stupid when I encounter a
>lock conflict.
>In the php logs I get:
>-501 Attempt to reclose a closed cursor
>invalid transaction handle (expecting explicit transaction start)
>what am I doing wrong?
>also, Why do I ALWAYS get a lock conflict when using prepared
>statements even if I only have 2 concurrent clients?

That's not a lock conflict. It's an unhandled exception.

>If do NOT use prepared statements, I rarely get lock-conflicts.
>exactly the same behavior.
>Code Snippet:
>$db = ibase_connect (...);
>$stmt = ibase_prepare($trans, "SELECT id FROM GET_ID(?,?,?)");
>foreach($entries as $entry){
> $res = ibase_execute( $stmt, $entry[0], $enty[1], $entry[2]);

Before probing too deeply, there are only 2 $entry assignments
here. If the snippet is copied from your actual script, then the
XSQLDA has prepared 3 XSQLVARs and the loop is populating $entries
with only two, with the second probably of the wrong type. (You
repeat the same typo, on the assignment to the second parameter, in
your retry). I suspect that the client is crashing because you
(don't seem to be) intercepting the exceptions in either case.

Just an initial thought on the situation...