Subject | Re: [firebird-support] Re: Potential computed by and UDF issue |
---|---|
Author | Helen Borrie |
Post date | 2005-02-09T00:35:03Z |
At 07:42 PM 8/02/2005 +0500, you wrote:
a non-existent problem. It WILL be a problem if you try to define computed
fields based on calls to UDFs that are not declared in the database, or are
incorrectly declared (which is not the problem that was reported here); or
if you base computed fields on references to tables, views or stored
procedures that haven't yet been restored. This latter *is* a known issue,
since restore restores each group of objects in alphabetical order, not
creation order.
Since the restore didn't fall over when creating the table (with the UDF
reference) but when trying to restore permissions, Rob needs to look at
the permissions and find the error there that is causing the restore to fail.
./heLen
>Hello Rob,No; it was touted as a possible problem. But, with respect to UDFs, it's
>
>r> Does anyone care to take this question on please? Is there somewhere
>r> else I should report potential bugs?
>AFAIK, it is a known problem: restoring of UDFs occures after
>restoring of tables, so computed field(s) cannot know your UDFs at
>restore time. As I've read earlier, FB2 will fix the problem (I may be
>wrong).
a non-existent problem. It WILL be a problem if you try to define computed
fields based on calls to UDFs that are not declared in the database, or are
incorrectly declared (which is not the problem that was reported here); or
if you base computed fields on references to tables, views or stored
procedures that haven't yet been restored. This latter *is* a known issue,
since restore restores each group of objects in alphabetical order, not
creation order.
Since the restore didn't fall over when creating the table (with the UDF
reference) but when trying to restore permissions, Rob needs to look at
the permissions and find the error there that is causing the restore to fail.
./heLen