""Leyne, Sean"" <sleyne@...> wrote in message
news:66187D861C1747499BE1365B74E03691015463@......

> >
> > What I wanted to demonstrate what this:
> >=20
> > SQL> create table cc(a char(30000));
> > SQL> select a,a from cc; =3D> 60000, ok
> > SQL> select a,a,a from cc; =3D> see this, it is 90000.
> > Statement failed, SQLCODE =3D -104
> >=20
> > invalid request BLR at offset 38
> > -Implementation limit exceeded
> > -block size exceeds implementation restriction
>
> Very interesting!
>
> I'll log both to the bug tracker.

I did myself with other bugs I had pending.

> One question though, why does returning 68,000 break the engine but
> returning 90,000 result in an error (without breaking the engine).

It's not the number, but the method. Using fields, the excess is detected.
Using hard casts of innocent integers, something goes bad (lack of check)
and some buffer is overwritten.

For impatient people: unlike the previous example that needs the ill-behaved
statement and any following SELECT, this one kills the engine by itself:

SQL> select cast(0 as char(32000)) || cast(1 as char(32000)) || cast(2 as
CON> char(32000)) from rdb$database;

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