Subject Re: [ib-support] Re: UDF Failure
Author Claudio Valderrama C.
""alex_vnru"" <ded@...> wrote in message
news:a7s9cu+u4kc@......
>
> select Trim(cast ('c' as varchar (32000)) || Cast ('c' as varchar
> (32000))) from rdb$database
> Unsuccessful execution caused by an unavailable resource.
> Implementation limit exceeded.
> block size exceeds implementation restriction.
>
> OK, intermediate result greater than 32767. On FB1.1 it should occure
> on 64K, if I confuse myself rightly :)

Near 64K, but some bytes less. If it doesn't happen, you will trash the
engine (and this is the minor problem, believe me).


> select Trim(cast ('c' as varchar (32700))) || Cast ('c' as varchar
> (32700)) from rdb$database
> Unsuccessful execution caused by an unavailable resource.
> Implementation limit exceeded.
> block size exceeds implementation restriction.
>
> Intermediate results are 1 and 32700, expression result is 32701 and
> less than 32767. Why statement is incorrect?

The check is made at compile time, do you understand that? The engine needs
to know in advance if it has enough legal buffer to answer and this is the
maximum possible value. This is the second time I write about the largest
possible value at COMPILATION TIME. What's the Trim declaration? Something
like

DECLARE EXTERNAL FUNCTION trim
CSTRING(256)
RETURNS CHAR (80) FREE_IT
ENTRY_POINT 'fn_trim' MODULE_NAME 'udflib';
???

32700 + 80 > 32K, that's all the mystery.


> select Trim(cast ('c' as varchar (32500))) || Cast ('c' as varchar
> (32500)) from rdb$database
> 'cc' || many spaces
>
> Intermediate results are 1 and 32500, expression result is 32501 and
> less than 32767 too. I can't realize difference between this statement
> and prior one, which produced an exception.

It takes a fool to create a silly statement. It takes a clever person to
create a worse case. The engine doesn't optimize silly cases. Also, the
engine doesn't make the deductions that for a person are obvious.
Look at the formal length declared for the UDF.


> Interesting is too that when I tried to overflow an operand, reaction
> was another, from DSQL
>
> select Trim(cast ('c' as varchar (32767))) from rdb$database
>
> Dynamic SQL Error.
> SQL error code = -204.
> Data type unknown.
> Implementation limit exceeded.
> COLUMN DSQL internal.

DSQL doesn't check in all places. It tries to stop you from creating fields
greater than 32765 and 32767. If it did all the required bound enforcements,
never users could have created concatenation of long varchars in stored
procs.

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