Hi Alexander,

> I think about external logic in the sense of database
> corruption and
> because about gfix I can't speak at forum where ladies are
> present. :)
> My idea is call UDF within such a triggers, this UDF should transfer
> data to some application server that stores this "transaction log
> emulation" on another computer asyncronously with .gdb processing and
> not perform delays. This log can be re-played on last copy of
> database
> in case of corruption.

In the couple of my apps all changes (read: the txn log) are stored by
triggers within the same (operational) database and all entries of this log
are asynchronously tranferred to the another (archive) database/file by a
separate daemon. In one of them, AfterCommit event of TIBDatabase is used to
wake up the daemon via IPC or Winsock and activate the archival process. In
other app, the daemon periodically transfers the data every given interval
of time. Both these tactics can be reimplemented to deal with external
files. If, AFAIU, you want to have all this stuff working in the database
and don't touch the client/middleware code, then I cannot see a way to go
for you now. Maybe further, with "after commit" triggers or cross-database
operations in procedures and triggers. Time will show...

Cheers,
Dmitry