At 01:55 PM 23-09-02 +0000, you wrote:

>The qry is always prepared. In FormShow, I prepare the qry. Do I
>have to prepare again, for when the qry uses the sql (Insert, update,
>Delete) on the UpdateSQL tab of the query editor?

Hmmm. Somehow I think this is the first time you mentioned you were using
custom DML. It might be revealing to see what the custom DML is for the
offending operation...

But no. IBO prepares the XxxxSQL statement when it is needed. If the
operation doesn't happen, it doesn't do it. Therefore, the relevant
statement isn't prepared. In any case, at FormClose IBO will unprepare any
prepared statements created by that form.

>My FormCloseQuery event now looks like this:
>
> ShowTransactionState()
>
> if ( qry->NeedToPost )
> {
> qry->Post();
> if ( qry->IB_Transaction->InTransaction )
> qry->IB_Transaction->Commit();
> }
> qry->Close();
> if ( qry->Prepared )
> qry->Unprepare();
>
>At the top of this event (ShowTransactionState) I print out the state
>of the Transaction:
>
> InTransaction: false

means there is no physical transaction in progress. Any data you can
see on the form is only in the dataset buffers.

> Started: true

means the transaction has been started but nothing (even a prepare) has
happened inside it yet. When a Prepare happens, InTransaction becomes true.

> TransactionIsActive: false

means the API has not passed an update/insert/delete statement across the
wire (i.e. posted); or has no edits/inserts/deletes awaiting posting.

> TransactionState: tsInactive

Same as TransactionIsActive = False.

>Further testing reveals the following:
>
>If I put the above code into an OnButtonClick, the code works OK with
>no "Statement has not been prepared", but the same code in
>FormCloseQuery gives the "Statement has not been prepared" error.
>I'm starting to think BCB is giving me the run around.

Or a timing issue: likely that, by the time FormCloseQuery fires, IBO has
already done the housekeeping on any lingering statements.

>Also, (with the code in the FormCloseQuery event)When the user has
>finished editing an item, I locate the row in the dataset using:
>
> TIB_LocateOptions lo;
> if ( qry->Locate( "USER_TASKS_ID", nTaskId, lo ))
> {
> // In my test case, I've commented the update code out
> }
>
>It seems that 'Locate' causes the "Statement has not been prepared"
>error. If I don't use Locate, then I don't get the error. Using
>Locate, even though I don't change the fields gives the error when
>the data is eventually commited and the form closed.

I'm confused as to why you are calling Locate() at all during an Edit. A
dataset's Insert, Update and Delete methods always operate on the current
record in the buffer - the one the cursor is on. Are you saying that you
let the user scroll around the dataset whilst editing an unbound control
pertaining to a particular record? If so, I guess you have some reason for
this...I'd always want to keep unbound edits securely pinned to the record
they belong to.

>Also the error appears after I've done all the post/commit/unprepare
>stuff, it seems to pop up when the TIB_Transaction & TIB_Query are
>being deleted with the form.
>
>....thinking of jumping out the window

Don't do it! No! Life is already too short! :-|
OTOH, if it's a ground floor window, the fresh air might help...

Helen