Subject | Re: [firebird-php] Re: Transactions with prepared statements CRASH. |
---|---|
Author | Fabio Gomes |
Post date | 2006-11-07T12:18:26Z |
Sorry if what i am saying is stupid but,
the syntax for the ibase_tras is: *ibase_trans* ( [int trans_args [,
resource link_identifier]] )
Aren´t you passing the parameters in the inverse order?
you are using: $trans = ibase_trans($db,
IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT);
shouldn´t it be: $trans =
ibase_trans(IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT, $db);?
I use ibase_prepare and ibase_execute in php without any problems, but i use
a linux server.
the syntax for the ibase_tras is: *ibase_trans* ( [int trans_args [,
resource link_identifier]] )
Aren´t you passing the parameters in the inverse order?
you are using: $trans = ibase_trans($db,
IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT);
shouldn´t it be: $trans =
ibase_trans(IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT, $db);?
I use ibase_prepare and ibase_execute in php without any problems, but i use
a linux server.
On 11/2/06, paulruizendaal <pnr@...> wrote:
>
> Actually, I think it is a fault in the PHP driver. My hypothesis is
> that after a transaction error all cursors on the attachment are
> invalidated that the driver then attempts to drop it once more.
>
> There are IBDEBUG statements in the source around the allocation and
> release of statements, so I assume it was something that Art was
> working on.
>
> What I need is a complete but simple script that shows the bug. Your
> example is nearly it, it just needs the initial connection and some
> table defs / data rows.
>
> Paul
>
>
>
--
.HELP SEX: This system is a computer and as such is not able to help with
enquiries of this nature. For details on reproduction, see the Xerox
documentation.
[Non-text portions of this message have been removed]