At 05:52 PM 15/12/2004 +0800, you wrote:

>Thanks, and hi again.
>
>Hmm, this is odd (at least to me).
>I did a "gfix -l" and this is what i got:
>
>Transaction 1561932 is in limbo.
>Could not reattach to database for transaction 1561932.
>Original path: 192.168.1.37:/var/firebird/db/erp_am.fdb
>Enter a valid path:
>localhost:/var/firebird/db/erp_am.fdb
>Could not reattach to database for transaction 1256282.
>Original path: 192.168.1.73:/var/firebird/db/erp_sd.fdb
>Enter a valid path:
>
>We are running a replication service for both these hosts, but I don't
>really understand the clear picture of what's going on here.

Well, limbo transactions occur during the commit phase of a cross-database
transaction, when the connection between the two servers is lost before the
two-phase commit completes. Both databases will have a limbo transaction
which you need to deal with, either by committing or by rolling back.

Here you seem to have two databases each with limbo transactions and the
server where you are running gfix can't find either of them. Why would
that be? Are there some servers off-line?

>Would it be safe to just do a "gfix -c all" ?

It won't break anything. But they will possibly except - which will leave
them in limbo -- after which you could only do a gfix -r all, I suppose.

I don't know what your replication scheme is but, if there is another
database involved, you will need to have it on-line as well.

If this has been a long term or repeating problem of crashing servers or
flukey network connections, it might take several go's to get all of the
limbo transactions cleared up. Once gfix -l has stopped reporting
transactions and you have resolved them all, a manual sweep should get
things moving again.

Sorry I can't be of much help but, if you are using IBReplicator, a visit
to that list might prove useful.

./hb