On converting literal strings into numbers: IDS 940 vs IDS 10
Hi.
At IDS 9.40 a query like this
select *
from a_table
where integer_field in ('12,1,2,8,3,4,7,8')
Works without error, even through expression '12,1,2,8,3,4,7,8' is evaluated as if it was '121283478'
At IDS10 query sends a -1213 character to decimal error, since the so-called convertion fails to fit result into an integer.
I'm aware that IDS10 interpretation of query is better than IDS940, also I believe that none of these behaviors are agree with programmer's intentions, but: is it possible to recover old behaviour via configuration on client or server, in order to don't get a catastrophic response from application.
Thanks in advance
Omar Muñoz.
On Jul 19, 12:25 pm, Omar Muñoz <omar...@yahoo.com> wrote:
> At IDS 9.40 a query like this
>
> select *
> from a_table
> where integer_field in ('12,1,2,8,3,4,7,8')>
> Works without error, even through expression '12,1,2,8,3,4,7,8' is evaluated as if it was '121283478'
>
> At IDS10 query sends a -1213 character to decimal error, since the so-called conversion fails to fit result into an integer.
>
> I'm aware that IDS10 interpretation of query is better than IDS940, also I believe that none of these behaviors are agree with programmer's intentions, but: is it possible to recover old behaviour via configuration on client or server, in order to don't get a catastrophic response from application.
The old behaviour was somewhat reprehensible - the handling of commas
in numbers presented as strings was lax, and still is a bit lax in
later versions of IDS, but less so than before.
Clearly, the code never worked as the programmer expected - there is
no way to get a list of numbers into an IN clause without generating a
list of numbers, and a string literal only contains a single number.
(You might be able to get fancy with LIST values or similar.)
AFAIK, there is no way to turn the switch back.
-=JL=-