> OK - Using gbak i get a 'closing' but no 'going home'. I see and

error

> message at the end : " (PK_FIB$Errormessages) writing constraints",

and

Is that an error message? Looks to me like you have a table
called 'FIB$Errormessages' and it is writing the primary key metadata
to the backup file. I am guessing that some tool has inserted some
tables into your database (guessing FIB).

I think the going home is just on the restore, you should get a line
saying

gbak: closing file, committing, and finishing. [?] bytes written

> backup file is pretty small compare to initial.

The backup file is usually smaller than the fdb file. It does not
contain garbage records, index pages (just what fields it needs to
create them again), etc. It is not unusual for it to be half the
size, although if the size of a backup file is significantly and
unexplainably different to a prior day then it may be worth
investigating.

For example, if your fbk file is 15000K one day, 15200K the next and
5K the next, you know there is a problem.

> Is there any tool to
> check the database integrity ?

The fastest and most accurate test is to restore the fbk file that
has just been generated (TO A DIFFERENT LOCATION THAN THE ORIGINAL
DATABASE). If the restore does not give an error, then it is probably
fine, but you may want to connect to it from iSQL or some other tool
for piece of mind.

gbak -c c:\myfbk.fbk localhost:c:\restored.fdb -user sysdba -password
masterke -v

Changing the path and credentials as required.

As a side note, the fbk file is extremely compressable. I use 7zip
for this. For example, a 200MB database can be reduced to about 80MB
using gbak, and the fbk file to 10MB using 7z. Using zip, you can
achieve about 15MB. This ratio is probably data dependent.

Adam