"Jim Starkey" <jas@...> wrote:

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

Sounds logical to me.

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

And here we have a conflict, as there are a few transactions that perform a
restore. When you commit table metadata to be able to store the data,
procedures are not yet committed (they belong to a different transaction).
At least this is what I see in the sources.

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

Then the entire restore should belong to a single transaction with almost
everything restored before tables. And in the case of broken procedure BLR
we'll get a restore failure without any data in the database. Is this what
you suggest?


Dmitry