|Subject||Survival of Prepared state was Re: just if you are curious|
>On Saturday 22 February 2003 18:33, you wrote:At 10:42 AM 23/02/2003 +0000, Phil Shrimpton wrote:
> > If I understand correctly, the JayBird driver doesn't allow prepared
> > statements to persist beyond a commited transaction.
>No 'component' set allows this, as FB does not allow this. Basically,Indeed FB does allow this. Commit with retain (implemented in Delphi
>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.
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
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
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...