| Subject | Re: [firebird-support] Restore ERROR "Invalid request BLR at offset.." Helppp¡ |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-02-25T01:55:52Z |
At 11:05 AM 25/02/2009, you wrote:
What it means is that, somewhere in the metadata of your database, a constraint trigger of some kind, or an expression index definition, or a COMPUTED BY field definition, or a view definition, is encountering an invalid SELECT expression on a stored procedure named CONCURRENCIA_CONCEPTO. This procedure CONCURRENCIA_CONCEPTO has been written as an executable procedure, not a selectable one that can return a set of rows, and so the operation fails.
********************
I hope you are not trying to restore the database by overwriting your good database. Make certain that the database being created by your restore attempts is being written to some location safely isolated from your good database.
********************
Under these safe conditions,
and
**provided you are using gbak and understand how it works**
you could try to restore the database using gbak -c with the -i[nactive] switch, to have the process not try to activate indexes. This might deal with the case where the error comes from a bad expression index definition.
Another alternative (under these safe conditions) would be to use the -n[o_validity] switch, to prevent the process from restoring CHECK constraints.
Neither of these things will get past the problem if it is a computed column that depends on this faulty procedure call.
Even if using either (or both) of these options succeeds in restoring your database, the database will NOT be in a production-capable state and the bug is NOT fixed. More intervention from the provider will be required to achieve that.
./heLen
>Please some body help me,It is a bug in the metadata of the database.
>
>I`m getting this error message when i try to restore our database, from
>a backup
>
>"invalid request BLR at offset 575, procedure CONCURRENCIA_CONCEPTO is
>not selectable (it does not contain a SUSPEND statement)"
What it means is that, somewhere in the metadata of your database, a constraint trigger of some kind, or an expression index definition, or a COMPUTED BY field definition, or a view definition, is encountering an invalid SELECT expression on a stored procedure named CONCURRENCIA_CONCEPTO. This procedure CONCURRENCIA_CONCEPTO has been written as an executable procedure, not a selectable one that can return a set of rows, and so the operation fails.
>I try to get help from our software provider but it suc**..i am not anIf you created this bug yourself, by meddling with the metadata of your database, then your software provider might be expected to be unsympathetic. If you are sure you are in the clear then you must persevere with your software provider, however frustrating it might be. If it is their bug then it is their duty to fix the bug and to recover your database.
>expert as you can see. Please any help will be appreciated.
********************
I hope you are not trying to restore the database by overwriting your good database. Make certain that the database being created by your restore attempts is being written to some location safely isolated from your good database.
********************
Under these safe conditions,
and
**provided you are using gbak and understand how it works**
you could try to restore the database using gbak -c with the -i[nactive] switch, to have the process not try to activate indexes. This might deal with the case where the error comes from a bad expression index definition.
Another alternative (under these safe conditions) would be to use the -n[o_validity] switch, to prevent the process from restoring CHECK constraints.
Neither of these things will get past the problem if it is a computed column that depends on this faulty procedure call.
Even if using either (or both) of these options succeeds in restoring your database, the database will NOT be in a production-capable state and the bug is NOT fixed. More intervention from the provider will be required to achieve that.
./heLen