Someone mentioned recently that we may be putting lots of
effort into the builds because we aren't comfortable attacking
the main code base. Here's a reasonably well-isolated project
that would be of benefit to Firebird users.
Gbak sometimes refuses to restore a database that it happily
backed up. Usually the problem is data that doesn't meet some
sort of defined constraint - often a null or duplicate in a
column (or set of columns) that should be unique. Why? Who
knows...
If there were a switch that told gpre, "just get the data, don't
bother with any rules" - well it would take business away from
IBPhoenix, but make the database more reliable.
When gbak restores a database, it first creates the metadata,
without defining foreign key constraints or activating triggers
or indexes. It creates the metadata through direct updates
to the system relations. From the metadata, it builds dynamic
queries to store the data. The changes (other than actually
handling the switch) will be in rstore.e, and will involve
skipping attributes in the backup file.
Any takers?
Regards,
Ann
http://www.ibphoenix.com
We have answers.
|
