> Do you have a recommendation for how I should check whether a .gdb
> file has changed since a previous backup?
>
> At first, I was going to use the checksum value returned by gstat, but
> found that feature hasn't worked for years.
>
> Now you are telling me file modification dates are irrelevant.
>
> Do you think this would work?
>
> 1) Run a gbak against the target file
>
> 2) get the file checksum of the target database AFTER gbak finishes
>
> 3) on subsequent backup attempts, if the checksum from #2 is different
> than the current checksum of the target database file, then perform
> another backup.
>
> Best Regards,
>
> David Montgomery

My case is different, obviously. I don't try to only backup the file if it's
been altered. I backup it up irrespective, every day on a 14 day recycle of
batch files using AT. I run a restore batch every 14 days, if it exits with
an errorlevel I send myself an email (blat). Then once every six months, I
manually restore a backup to watch it happen.

If you absolutely must only backup the file if it's been altered, then I
would think of adding a trigger to one or all tables on update/insert.
Insert a record into another table - if you insert into an external table,
it will not rollback under transaction control (I think). Then you could
check the external table, back up the gdb if you want, then maybe delete the
record in the table.

The trigger would need to check first if a record exists int he external
table (no need to add a second record). I would then question this method as
to the overhead it imposes on the database under normal interaction compared
with just backing up the file regardless of it's state.

On my websites, where small databases are concerned, I zip the backup and
email (blat) it off to myself so there's always a history of backups.

Alan