Subject Re: [firebird-support] BLR Offset
Author Helen Borrie
At 04:24 PM 13/04/2005 -0700, you wrote:

>Helen Borrie wrote:
> > At 02:47 PM 13/04/2005 -0700, you wrote:
> >
> >
> >>Microsoft OLE DB Provider for ODBC Drivers error '80004005'
> >>
> >>invalid request BLR at offset 1 BLR syntax error: expected Invalid BLR
> >>code at offset 1, encountered 177
> >>
> >>/fbonline5/includes/main.asp, line 2485
> >>
> >>
> >>What would cause this? I have the exact same database using the same
> >>driver on my system and it works fine, on my clients machine they get
> >>that message. We are both using the same version of Firebird and the
> >>same version of the firebird odbc driver
> >>
> >>What is it saying to me?
> >
> >
> > If the error message reported above is a faithful copy of the error
> message
> > you saw, then one thing it's saying to me is that something is definitely
> > screwy when the interface is scrambling the text of an error message
> string.
> >
>Which part is scrambled?

All of it. There are pieces of two error strings here for two (related)
errors, viz.

isc code 335544343, symbol invalid_blr:
The message format in Firebird 1.5 is:
Invalid request BLR at offset %ld


isc code 335544390, symbol syntaxerr
Message format:
BLR syntax error: expected %s at offset %ld, encountered %ld

It's impossible to know how or why this distortion occurred when the
interface interpreted the status array. It could be that your client's
system isn't accessing the correct Firebird client library and message
file. That might be the case if they have artifacts left over from a
Firebird 1.0 or InterBase installation. It would at least be worthwhile

btw, BLR is a kind of pcode that sits between SQL and the engine. Amongst
other things, it's the code from which stored procedures and triggers are
compiled and views are accessed. BLR is also created at run-time for DSQL

Is it possible that the "identical database" isn't identical at all, but a
corrupt copy? Was it installed by restoring from a gbak, or did you
file-copy it? Is it possible that you had changes pending to a stored
procedure, view or trigger at the time the gbak or file copy was taken?