>On Saturday 22 February 2003 18:33, you wrote:
>
>Hi,
>
> > If I understand correctly, the JayBird driver doesn't allow prepared
> > statements to persist beyond a commited transaction.

At 10:42 AM 23/02/2003 +0000, Phil Shrimpton wrote:

>No 'component' set allows this, as FB does not allow this. Basically,
>everything in FB is only valid within the context of a transaction, when the
>transaction is closed (committed or rolledback), everything belonging to that
>transaction becomes invalid.

Indeed FB does allow this. Commit with retain (implemented in Delphi
components as CommitRetaining) opens a new transaction after committing,
using the same transaction context as the one just committed. Anything
prepared in that transaction remains prepared in the API structure that is
returned.

Does the Jaybird driver not support CommitRetaining?

In fact, all data access components I have used with Fb/IB support keeping
statements prepared until explicitly unprepared (by deallocating the
statement handle). IB Objects components certainly support it, even if the
API doesn't. The original "Prepare" causes a chain of events that includes
creation of a persistent client-side structure (Params[]), which is not
disposed of unless the output structure of the statement is altered. So,
you can call Commit on the transaction, apply a new set of values to input
parameters, and go again, without triggering off the unprepare/prepare
cycle.

Maybe statement handles are not as tightly bound to transactions as you
suppose. It's certainly true that a statement handle can't be allocated
except within an existing transaction context. But maybe there is some
flag there that lets the programmer decide whether to hold or release the
statement handle on a hard commit/rollback...

heLen