Dmitry Yemanov wrote:

>"Jim Starkey" <jas@...> wrote:
>
>
>>>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.
>
>

There may be a bug, but the bug isn't in gbak, it's in the engine, which
is probably why it hasn't been fixed. UDFs in default values, computed
by expressions, and validation expressions were support since Interbase
version 2 when I first implemented UDFs. I mean, really, what is the
point of UDFs if they aren't easy to use?

Gbak is a layered utility, which means that it uses the published API.
If we can't figure out how to make the API work, how can we expect our
customers to figure it out?

I strongly suspect that the problem is in the dependency management
code, which was added by Borland. The original philosophy was to be
tolerant of change rather than trying to manage dependencies. In other
words, if somebody deleted an object referenced by something else, that
was OK as long as it was replaced before the next reference. If not,
then a clean runtime error was issued. When something was defined, the
engine automatically did what ever was necessary to splice it into
existing data structures. Much easier to use, explain, and implement
than the dependency management crap.

>>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.
>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.
>
>

That just plain silly. It may be the way it has evolved, but it wasn't
the way it was designed, implemented, or intended to be. The whole
point of deferred work blocks was to handle the ordering of internal
operations so the user didn't need to.

The problem is a misunderstanding of the system architecture. Gbak is a
layered utility that serializes data in a logical order that it can
later restore. The engine, in turn, handles the system table updates
and performs the necesary behind the scenes changes for the internal
data structures and the "internal" system tables. If you try to fix an
engine bug in gbak, you're going at the problem incorrectly.

>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).
>
>
>

In the case in point, as long as UDFs are restored before global fields
(and why wouldn't they?), there should be no problem. BLR validation,
if any is actually necessary, can always be deferred as the last step of
DFW handling. If it were up to me, I'd skip BLR validation until first
reference, but this does fly in the face of the assumption that users
are idiots and don't test their code.