At 09:58 PM 23/08/2004 +0200, you wrote:

> > You have corruption there, the kind that, unfortunately, seems to happen
> > when you have a damaged or dying disk.
>
>It's not the disk. I have been on a exhibition and I had to configure some
>notebooks for replication. We use IBReplicator for this. Configuring
>replications means, that IBReplicator creates some triggers for logging the
>data changes on the local database as well as on the server database. I was
>connected to the server database via ISDN and sometimes while creating the
>triggers on the server database the ISDN-connection was interrupted. And then
>the server database was corrupted.

Creating/changing metadata isn't the same as changing data. I'm sure
IBReplicator does have *some* strategy for managing a two-phase commit for
metadata commits, though I don't know what it is. I would suppose that, as
a minimum, it would be totally separated from the data replication and
wouldn't be allowed while replication was going on...

>This behaviour is reproducable, when I create trigger on the server
>database and interrupt the connection, the the database is corrupted.

Databases get corrupted when you post data while metadata changes are yet
uncommitted. That's true, even without a two-phase commit. In a two-phase
commit you have the situation where transactions are in a limbo state in
both databases until the final commit has happened in both databases, i.e.
the transaction has a full accounting of the posts in both databases and
the work is clears for committing in both databases. Until THAT commit
succeeds, it's not safe to start posting data to the user tables.

>Do you have any idea, why the database gets corrupted?

Yes, I would suppose that uncommitted metadata changes are left sitting in
limbo transactions when the connection breaks. Then, when the connection
resumes, and data starts to flow, the transaction accounting is gone or
messed up and corruption results.

>I thought, when the transaction, in which the trigger will be created,
>can't finish, all the changes will be rolled back.

No, not in two-phase commits. If a 2pc transaction commits, and the second
phase is interrupted, the transactions are left in limbo state. The limbo
transactions in the system tables in both databases would have to be set
right before you begin posting data.

I'm working on supposition here: I'm sure that IBReplicator has some
safeguard that can be configured to guard against what you're
observing---or, at least, some procedural No-No regarding attempts to run
2PC metadata transactions concurrently with data replications.

The right place to ask about this would be the IBReplicator list. Don't
forget to provide a proper problem description, including version numbers
of everything. The support lists don't support NPC (n-Phase Comprehension).

./heLen