--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 02:12 PM 27/07/2004 +0000, you wrote:
>
> >This is very helpful, Thanks. Now an addition tidbit. I am
> >encountering this error when retrying an a select statement after
> >encountering a limbo transaction error. So does this mean the
> >transaction is out of limbo state and the query has proceeded

before

> >I retry? What is the best way to handle limbo transactions errors
> >encountered during a query?
>
> Uh-oh, this could be a different sort of sync error altogether.

Limbo

> transactions don't arise in a transaction involving only one

database, and

> limbo transactions have no capability to "unlimbo" themselves. A

limbo

> transaction is a two-phase, multi-database transaction that gets

left in an

> indeterminate state when the connection is lost to one or other

databases

> before the two-phase commit completes.
>
> If you are getting messages about limbo transactions, you'll need

to fix

> them. This requires use of the gfix utility and Chapter 39 of The

Firebird

> Book (coming real soon! :-) ) Absent The Firebird Book, study the
> relevant section in the IB6 OpGuide.pdf.
>
> /heLen

Helen,

Am I incorrect in thinking that I can get isc_rec_in_limbo status
returned when a transaction is part way throught the 2 phase commit
process to multiple databases?

If process A commits 1 record to table FOO on machine x, and y. Then
process B recevies a event saying table FOO had an insert, so process
B does a selectALL on FOO while process A is part way through the 2
phase commit between x and y doing an update on FOO. Can the
isc_dsql_fetch done by process B return isc_rec_in_limbo? That is
what I am seeing. When I retry the isc_dsql_fetch after waiting a
bit, I get the isc_rec_sync. The transaction that process A commited
across the machines x and y is not in limbo on either machine
according to process A. The commit returned success.

Thanks
Kevin