Hi

My mistake...the JayBird DOES support commit retaining.....but only at the
lowest (FB API) level.
The JDBC functions do not use them, as I see this code somewhere
in a file called FBDatabaseMetaData.java. Seems like it's hardcoded.

public boolean supportsOpenStatementsAcrossCommit() throws SQLException
{
return false;//commit retaining only.
}

AFAIK, JDBC does not have a "CommitRetaining" function. (Neither does
ADO/OLEDB
if I understand correctly). A connection url switch to toggle commit
retaining function
might be useful in this case, since I suspect it could help out with
performance especially
if we're using some O/R mapping tool...

I'm cross-posting this to Firebird-java, as it seems to be more relevant
there...

Regards
Kenneth

----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <ib-support@yahoogroups.com>
Sent: Sunday, February 23, 2003 10:38 PM
Subject: [ib-support] Survival of Prepared state was Re: just if you are
curious


>
> >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
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>