| Subject | Re: [firebird-support] Restore ERROR "Invalid requ est BLR at offset.." Helppp¡ |
|---|---|
| Author | MARIO RODRIGUEZ |
| Post date | 2009-02-25T02:57:59Z |
I´ve installed firebird server 2.1 on our server, instead of 1.5 (used by provider) is this a serious problem?..maybe this can cause this metadata bugs?..I did this long time ago.
..yes..i know i made a big mistake but i think that our provider is taking advantage of this...am i rigth? they said "sorry we can´t support you any more"
Thank you very much i realy apreciated
Best regards,
Leo
________________________________
De: Helen Borrie <helebor@...>
Para: firebird-support@yahoogroups.com
Enviado: martes, 24 de febrero, 2009 20:55:52
Asunto: Re: [firebird-support] Restore ERROR "Invalid request BLR at offset.." Helppp¡
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
¡Sé el Bello 51 de People en Español! ¡Es tu oportunidad de Brillar! Sube tus fotos ya. http://www.51bello.com/
[Non-text portions of this message have been removed]
..yes..i know i made a big mistake but i think that our provider is taking advantage of this...am i rigth? they said "sorry we can´t support you any more"
Thank you very much i realy apreciated
Best regards,
Leo
________________________________
De: Helen Borrie <helebor@...>
Para: firebird-support@yahoogroups.com
Enviado: martes, 24 de febrero, 2009 20:55:52
Asunto: Re: [firebird-support] Restore ERROR "Invalid request BLR at offset.." Helppp¡
At 11:05 AM 25/02/2009, you wrote:
>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
¡Sé el Bello 51 de People en Español! ¡Es tu oportunidad de Brillar! Sube tus fotos ya. http://www.51bello.com/
[Non-text portions of this message have been removed]