Hmm. I did have a table that had some large varchar fields in it... The
odd thing is, this table has been accessed in the same way almost every day
for over a year, without causing any problems. o_O I reduced the field
sizes and the problem seems to have gone away.

Thanks.

-----Original Message-----
From: news@... [mailto:news@...]On Behalf Of
Claudio Valderrama C.
Sent: Thursday, February 14, 2002 1:29 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] gds_$compile_request failed error message


""Mark Shapiro"" <shapirom@...> wrote in message
news:NBBBJFDMLBCCJIDNOIIFGECNLIAB.shapirom@......

>
> The error messages are:
>
> Invalid request BLR at offset 21
> Implementation limit exceeded
> Block size exceeds implementation restriction
> gds_$compile_request failed

Do you have a statement that retrieves a lot of fields and they are long?
Do you have really a monster procedure doing big SELECT statements?
Do you join views where each one produces a lot of long fields?

This message is telling you that the engine cannot return a message longer
than MAX_FORMAT_SIZE, that happens to be 64K-1.
The message length is the sum of its parameters' length. (This is internal
stuff, nothing that you're going to control in a stored proc directly.)

For example, this is possible:

SQL> select cast(0 as char(32000)) || cast(1 as char(32000)) || cast(1 as
char(2000)) from rdb$database;
=> ok

But this may cause problems:

SQL> select cast(0 as char(32000)) || cast(1 as char(32000)) || cast(1 as
char(4000)) from rdb$database;
================
²²²²²²²²²²²²²²²²
[snip]
²²²²²²²²²²²²²²²²
Statement failed, SQLCODE = -901
connection lost to database

Oh [red face], my example was extreme, I broke the engine! Do you want
another item for the bug tracker, Sean? <g> Certainly I wanted to
demonstrate the BLR error, not this. Using cast(), I threw the engine by the
window! It seems that I need two executions to kill the engine (the second
fails while being prepared), and the failure happens inside gds__free().
This means corrupted memory that the first run left.

What I wanted to demonstrate what this:

SQL> create table cc(a char(30000));
SQL> select a,a from cc; => 60000, ok
SQL> select a,a,a from cc; => see this, it is 90000.
Statement failed, SQLCODE = -104

invalid request BLR at offset 38
-Implementation limit exceeded
-block size exceeds implementation restriction

And this is the message I was prepared to reproduce. I hope I won't have to
live the equivalent Bill Gates' shame in that demo of Win98 when it crashed
in a simple Plug And Play test in front of the public, when it was being
launched officially. This is why I don't do IB/FB public presentations, less
even a demo.
:-)

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/