Ann,

> At 07:56 AM 9/5/2002 +0200, Boguslaw Brandys wrote:
>
> >As I understand You are talking about a journal to separate process (an
> >later to an external file).
>
> Actually no, the database server itself writes to the journal
> file.

I must ask : where is this journal file ?

> >This would be great for some replication schemma
> >(one database is Master another - Slave like in MySQL)
>
> That's actually reasonably easy to implement with triggers and
> events. I'd worry quite a lot about using code that has been
> not been tried in nearly 12 years, given that there is an reasonable
> external way to get that job done.

I agree, but It must be done in each database once again (since I don't see
system triggers in Firebird/Interbase -only table/row based.

> >I was thinking about something different : how to use existing feature of
> >Interbase (record versioning) for avoid redo log completly.
>
>
> That's an idea that comes up from time to time. There's considerable
> value in being able to recreate the state of the database just before
> something dreadful happened. Adding eight bytes to every record is
> quite expensive. One might, as an alternative, log the next transaction
> id every 10 minutes or so to create a timeline. Then, if garbage
> collection were disabled - or relegated to a special process that
> understood how long the old versions were needed - a recover process
> could be created that would move the database back to a specific time,
> more or less. All transactions that had started at that time and
> eventually committed would be considered committed.
>
> The cost of turning off garbage collection is the open question.

So ,it is open for discussion.

Best Regards
Boguslaw