Re: [Firebird-devel] Database restore fail - Invalid request BLR at offset 2. Function ROUND is not defined. Help!!!!

[Dmitry Y. <di...@us...>]

"Leyne, Sean" <Se...@br...> wrote:
>
> Why does the BLR for COMPUTED columns get reevaluated during the
> restore, whereas the BLR for Views does not?

BLR parsing is done on commit for all object types.
Procedures/triggers/views are committed at the end of restore. All metadata
rows are actually restored at this stage, so metadata cache lookups are
successful. But tables are committed immediately (to allow data to be
stored):

 * Write relation meta-data and data.
 * Use the default transaction for RELATIONS,
 * and use the global_trans for VIEWS.  This
 * enables us to have views of SP and views
 * with plans.

So when a table metadata containing computed BLR (as well as
default/check/etc) is committed, there's no UDF (or any other object)
references in the cache, hence a failure. A workaround is to
use -one_at_a_time switch of GBAK which disables per-table commit mode. All
databases with computed columns I've seen so far are being successfully
restored using this switch.

The default incremental mode allows you to restore and commit as many data
as possible in the case of backup breakage, but it's not friendly to
computed columns. The -o switch allows you to restore all metadata, but with
some risk to end with a completely empty database.

BTW, the reported error is always "cannot find table/procedure for grant".
Why? Because table hasn't been restored (metadata commit failed), but its
privileges are still being restored later, obviously causing a failure.


Dmitry