At 02:02 PM 18/03/2003 +1000, you wrote:

> > 3. once quite infrequently (perhaps 2 times a year)
> > your backup is restored to another name adjacent to real database then the
> > real one is renamed to "oldXXX" and the restored original file is rename
>to
> > "your real dbname.gdb"
> > step 3 has to be done while noone is connected - you have to manage this
> > process somehow.
>
>This really comes down to the root of the problem.... I am trying to do
>this process regularly. You have said to do it infrequently (twice per
>year)
>I am looking to automate this process as much as possible. You have
>described a process very similar to my current approach, just varying the
>times.... What can I do to be sure that I can safely rename one file to the
>other? Should I be using MoveFile instead of CopyFile? Is this the answer?

You shouldn't be using any sort of file copy on a database where the server
is running. Just doing *this* will not just produce a corrupt copy, it
will also potentially corrupt the database file which you are copying,
because file copy utilities lock sectors of the physical disk, which could
contain structures that open transactions are writing to, have uncommitted
record versions in, etc.

Did you realise that gbak is NOT a file copy utility?

On your questions in later messages, there is nothing *wrong* with doing a
gbak backup and a gbak restore once a week if you need to. Performance
will tell you how often you need to resort to this type of hygiene.

Restore the gbk file using gbak -c to a *different* place on your
filesystem. Connect to it to verify that all is OK; then disconnect and
then shut down the server.

Rename the original, file-copy the restored db across and then rename *it*
to the real db name.

Don't rename database files to ".gbk" because, for sure, someone will try
to use it as the source of a gbak -c and think it's corrupt because it
can't be restored-from.

heLen