At 04:56 PM 26-01-02 +0000, you wrote:

>I have posted the gbk file in files section...
>I made many backup/restore last month with Rc2
>and all work fine. But this one wont work! the
>gdb work fine, the gbk wont restore.

You have a data problem in the current version of the database. If you have a copy of the gdb file, open it and fix the entries in the column ACCESSORI.

If you don't have a copy of the gdb file, then you have just learnt the hard way why it is not a good idea to restore backups over the top of your existing gdb file.

If you have no gdb file, and need to work on the gbk file to recover from this corruption, get a copy of the paper Diagnosing and Repairing Database Corruption by Paul Beach, http://www.ibphoenix.com/ibp_db_corr.html

and follow it exactly.

You will also need to eliminate the mechanism by which it was possible to enter data which were contrary to constraints.

>So the question is how secure is a gbk file?

The gbk file is not a copy of the database. It builds a complete metadata framework of your database and stores the data separately. When it restores, it completely reconstructs the database and identifies any corruption. This is what it has done in this case.

It is your procedure which is insecure. *Never* restore a backup so that it overwrites the current database. Always move it to a holding place, either on your system or offline. Make certain when file-copying the database (e.g. with copy/cut and paste or with winzip, etc.) that NO users (not even sysdba) are connected.

It is fine to run a gbak backup while users are connected.

>Or what goes wrong with this gbk?
>Remember i had two gbk files taken all two
>backup show no problem, but all two gbk wont restore
>them.

If you were able to restore previous gbk files then the corruption has occurred since the last gbak.

regards,
Helen


All for Open and Open for All
Firebird Open SQL Database · http://firebirdsql.org
_______________________________________________________