Hi !

I have a second case, when my FireBird database is corrupted.
But I don't understand the gbak's philosophy.

In first case the backup is working fine, but the restore is halted by
an error message: gds ... length error (252 needed, 249 coming).

In next problem (happened in yesterday) the gbak is working good in
backup, but restore is say that "Arithmetic Overflow or String
Truncation error"... Ahhh...
When I try to empty the table (what restore show, when it is halted),
the restore is say same error msg in another table.
And when I empty all table it is halted again - and say that error in
a generator restoration.
So (I think) that FDB file is corrupted.

But: in every cases I'm very lucky man, because from Delphi copier
program I can recreate the database.
(Create tables from Meta, Copy Datas, and ISQL exec every other
metadatas below Table creation section...).

But !!!

These cases, and some other cases, when the restore is halted by a
constraint that added later than datas (and datas are invalid WITH
this constraint), makes me very unhappy.

I think, that backup is not usable for SAFE data saving.
These cases are shows to me, that the silent backups without
errormessages are not same things like "THE DATABASE IS SAVED, AND
SAFELY RESTORABLE" methods.

MySQL, and PGSQL is save the datas with DUMP, with inserts (but I
don't know, how the blobs are saved...).

FB is follow the "binary backup" way.
But it is not too good, because the gbak is CAN CREATE the backup
without error reports, and CAN CREATE a backup that is un-restorable.

How to I put faith in backup files, when I not sure that backups are
restorable later ???

I this time the file copied database is better then only gbak saved
database...

I think, that the method is wrong.

If the gbak is working, that it MUST (!!!) show the errors that it
found in database: the datas that not restorable (because them later
constrained, and value is not corrected), the length errors, the db
validity errors, and others.
And it MUST say "Finished, no error", when it is SURE that the datas
are restorable.

And restore is CAN put a null fields to a record, if the gbak is save
NULL for these field - no matter, how the fields are constrained.
(Just show the comments in a file - that, and that record is
containing null, and the null are not allowed.)

THAT IS A GOOD SOLUTION.

In this time I say: I can put backup to my CRON jobs, and I'm sure,
that what the gbak is saved, I CAN RESTORE LATER !


Uff. I say that.