""alex_vnru"" <ded@...> wrote in message
news:a7qkad+kcvk@......

> --- In ib-support@y..., Paul Reeves <paul@f...> wrote:
> > iananewby wrote:
>
> Paul, sorry if I repost, first message walks for a couple of hours
> somewhere. I have a doubt: is it correct to check not an aexpression
> result but operands declarations or intermediate result (I'm not shure
> what's done)?

Fields up to 32K. Expressions up to 64K, but only the core engine cares.
DSQL may mangle anything.

> Next statements should provide result within range but
> are rejected now:
>
> Trimmed result of concatenation
>
> select Trim(cast ('c' as varchar (32000)) || Cast ('c' as varchar
> (32000))) from rdb$database

This is human inteligence. The engine only measures the declared length
because it needs to allocate resources. Those resources (for a row) can't go
above 65535 in any case, there's no way the internal code can cope with it.

>
> Trimmed first operand
>
> select Trim(cast ('c' as varchar (32700))) || Cast ('c' as varchar
> (32700)) from rdb$database
>
> In last it seems something wrong with check itself, because
>
> select Trim(cast ('c' as varchar (32500))) || Cast ('c' as varchar
> (32500)) from rdb$database

The DSQL layer can do whatever it wants. And if you want to fool it to kick
yourself, feel free to do so. The core engine can't be fooled directly for
64K and above. If the DSQL layer wraps its counter, the core engine will see
the wrapped numbers and will allocate only those resources. If the mangled
numbers are less than 64K, the request is accepted. Of course, you will get
different results than expected.

Anyway, it didn't understand a bit what your examples mean. Can you clarify
what's the ones you expect to be rejected and what fail at least?

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