Fabiano Bonin wrote:

>
> I'm making some tests on a database, changing system tables and other
> non recomended things... To more precise, i am deleting all foreign
> keys, primary keys and indices (in the right way) and changing the
> domain of some fields in the system tables (ex: update
> rdb$relation_fields set rdb$field_source = 'PS_DATA' where
> rdb$field_name = 'DATA' and rdb$relation_name = 'FER1'). The domains
> are always equal or larger in space compared to the original field
> type.

Without knowing exactly all of the changes you're making its very hard
to guess what the results will be. If, for example, you change the
definitions of the system tables themselves, you're very likely to get
into serious trouble. My guess is there's a dangling dependency
somewhere on a deleted primary key or a trigger that used to handle
ON UPDATE or ON DELETE actions.

> After running the tests, i do a backup of the database and it runs fine:
> gbak:writing SQL role: PSINIT4_TOOL
> gbak:closing file, committing, and finishing. 774000640 bytes written

The backup does next to no validation - if it can read the metadata and
the metadata corresponds to the data, the backup will succeed. If the
constraints or triggers are not consistent, the backup won't notice but
the restore will fail.

>
> So i do a restore in a new file. In the end of the restore process, i get:
> gbak: committing metadata
> Segmentation fault

Metadata is validated on commit.

>
> My questions are:
> - Should i expect this kind of error with a valid backup file, that
> was done without problems?

Yes.

> - What can cause this error, since the restore cycle went up to its
> end without any kind of error?

Inconsistent triggers, views, constraints, etc.

It might be worth while to test this a bit further and identify the
change that causes the segmentation fault, because that's not the way
it should fail.


Regards,


Ann