> > >AFAIK, the main problem is in GBAK that will need to manage more
> > >dependencies.
>
> Adriano is correct.
>
> > Gbak? Gbak is a backup and restore utilities -- it serializes metadata
> > and data in an order than can be readily restored.
>
> Exactly. And a simple default clause referencing UDF (even not considering
> selects and procedures) makes a database backup unrestorable. The same

issue

> exists with computed fields. You may find an example in SF #1047576. So

far

> the conclusion is that both backup order and restore transaction

management

> require modifications.
>
> >From the top of my head: all metadata containing BLR is globally

committed

> at the end of the restore process. But relations must be committed in
> advance (in order to store data) and IIRC also in different transaction.
> When table BLRs (defaults, computed, etc) are parsed, we cannot resolve
> references to other stored objects in the cache and get the restore

failure.

Beats me, but why exactly is it parsed? I thought gbak just "stored" the BLR
and data?

> The known workaround is to use -one_at_a_time switch (which AFAIU commits
> metadata step by step), but I'm not 100% sure it works for all cases.
>
> There were suggestions to adjust the backup order to take all possible
> interdependencies into account. But I'd better teach GBAK to modify

objects

> (instead of always storing them) and then separate "physical" table

metadata

> (the one defining its format) and BLR table metadata. The former would be
> committed immediately while BLRs would be added in the context of the

global

> transaction and committed later (as other objects are processed).

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com