Claudio Valderrama C. wrote:

>
> The fix is trivial if you consider that restore() is just a loop waiting for
> any type of registered objects. I never understood why backup() does (IMHO)
> a silly order to store objects. I would have stored first all object types
> that can't depend on other things. Once you change the backup order, there's
> virtually nothing else to do in the other side.

GBAK restores tables first, because it considers data the only thing
being important. Everything else is restored later, after the data has
been committed, so any BLR issue during restore won't cause a data loss.
Any attempt to solve this issue "trivially" and restore
generators/UDFs/etc before tables will break the aforementioned rule and
open an ability for the data being unrestoreable.

IMO, a correct fix should be to restore the minimum tables/fields
information (only what's required to establish a table format), then
restore data and only then add constraints, defaults, computed fields
etc -- i.e. all the stuff that may contain dependencies or invalidate
existing data. As for the "correct" restore order of BLR objects, I'm
not sure it's very important - everything is restored within a single
transaction and validation is performed upon commit (DFW stages 3-4),
when system tables already contain all metadata, so dependencies should
be tracked without problems.


Dmitry