Hi all -

We have started seeing this error message from time to time. Once it
shows up, the application can no longer talk to our FB test server.

Despite the contents of the message, it appears to really mean
"invalid transaction handle" as it shows up in contexts where there
is only a transaction handle; moreover, it looks like there was a
tracking issue on 2.1 saying that the error message was wrong. We
are using 2.0.0 final embedded for the client library (we also use
the embedded server.)

We have wrapped the FB API in C++ classes that carefully guard access
to the FB handles. The wrapper for isc_tr_handle only passes its
handle to the following APIs:

isc_start_multiple
isc_commit_transaction
isc_commit_retaining
isc_rollback_transaction

isc_dsql_execute_immediate
isc_dsql_execute
isc_dsql_prepare
isc_blob_lookup_desc

After isc_commit_transaction and isc_rollback_transaction, we set the
handle to NULL (as it is now invalid).

Looking at the source, it seems that I recently added some code that
would set up a situation where we commit a transaction which still
has a statement open and then create a new transaction and
statement. These two are used and deleted before disposing of the
first statement. Everything gets cleaned up eventually by C++
destructors, but I am wondering if this situation causes some table
inside the client to get corrupted from time to time.

Anyone have any ideas on this? is it bad juju to commit a
transaction while still holding on to statements?

TIA,
________________________________________________________
Richard Wesley Senior Software Developer Tableau
Software
http://www.tableausoftware.com/





[Non-text portions of this message have been removed]