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

Sounds logical to me. However, I would suggest a way to get the "invalidated
objects" or a list of objects that reference a particular object so at least
you
can CHECK to see if an object is still valid or generates an error. Else,
you could end up deleting objects without knowing it will error out on you
somewhere else.

I do like this idea though, it would avoid a lot of "drop view, create view"
craphola.

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

See above. :-)

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