At 08:15 PM 29/11/2004 +0000, you wrote:

> > >>I create tables with computed fields. For example in one table I
> > >>declare field like :
> > >>SYMB varchar(2) computed by (substr(SYMB_FULL,1,2))
> > >>
> > >>Everything works good till I must do backup and restore database.
> > >>Backup is OK, then in restore, I get error that function SUBSTR
>is
> > >>not existing - so table is not created, restore stops. For every
> > >>table in which I have computed fields which uses stored
>procedures
> > >>this error occurs.
> > >>So, to make backup and restore - first I must drop every
>calculated
> > >>field, next do backup, restore and finally create them back.
> > >>
> > >>Am I doing something wrong? Can I do it in other way?

Use the internal function SUBSTRING instead.

>It is not good to use computed fields on this kind?

Thanks to a very long-standing bug/wrong design decision in gbak, no, it's
not safe to define COMPUTED BY columns or domains that use UDFs, because
gbak restores UDF declarations *after* it has restored tables.

> Boguslaw Brandys:
> > Bug report:
> > https://sourceforge.net/tracker/?
>func=detail&atid=109028&aid=429594&group_id=9028
> >
> > Is it really still open (for 1.5.2 RC3) ? How about Firebird 1.0.3
>and > this bug ?

Yes, it's still open and won't be fixed in v.1.5.2.

>I tested this on FB 1.0.3 and 1.5.1 Bug occurs on both versions.
>It's big problem for me - or I must rewrite code of quite smart app.
>Maybe someone will resolve this, in near future?

Maybe.

./heLen