Jerzy,

I think this thread as been a mix of things. Security from
a rogue employee vs. disaster recovery. The former is a
problem with personnel the later is something a database
engine should be well equipped to handle. InterBase already
does a great job of this and likely could be made to do it
a bit better too.

> I view journaling as a tool for disaster recovery.

I would too.

> However, when you approach hundreds of GB

I think the community needs to sit and think hard about
how to best manage very large databases. GBAK.exe
is not a well suited mechanism for very large database
recovery.

> I like Jason's idea of the freezepoint.

How do you guarantee that something behind the freezepoint
has not become corrupt or maliciously damaged from the
time in which you set it?

> I think it would be an elegant solution to my needs.

What if the first page of the database is the corrupt
one? The data on disk is not guaranteed to be written
our contiguously in a production system. Only when
gbak creates the original file can this be ensured.

This is a good discussion. I think it would be more
productive if we all agreed on exactly what shortcomings
we were trying to address as a way to come to the best
solution.