Re: big int to ESQL
"Jonathan Leffler" <jleffler@earthlink.net> wrote
> Right - it isn't documented that ESQL/C understands long long, and it
> doesn't.
>
> > I know int8 in informix is machine independent and is a struct and ESQL/C
> > is suppose to use that struct. But that would mean a huge change in our
> > code. So I have written a small function to convert int8 to a long long value.
> >
> > create function biginttochar(p_int8 int8) returning char(19) ;> > define w char(19);
> > let w = p_int8 ;
> > return w ;
> > end function ;
> >
> > In ESQL/C
> >
> > $ long myvar ;> >
> > $ select biginttochar(fld1)
> > into :myvar
> > from ...> >
> > works fine till the value of fld1 is 2^31-1 which is 2,147,483,647.
> > After that it spews error -1215.
> >
> > So how to declare a long long int in ESQL/C.
> >
> > IDS 9.21.UC4
> > ESQL: 9.16.UC1
>
>
> You need to upgrade your ESQL/C - not because it provides a solution
> to the problem, per se, but simply because 9.16 is very old (and 9.21
> is not very current either - consider an upgrade for that, too).
>
> You have to use either ifx_int8_t structures, or you have to use
> DECIMAL(19) or larger. Both work. You then have to separately write
> code to stuff that into a long long, or to stuff a long long into the
> other value. The ifx_int8_t was introduced a year or two before
> 64-bit integers became ubiquitous. In theory, you should be able to
> convert an ifx_int8_t into a long long and vice versa with a little
> bit twiddling. I haven't done the experimentation to find out which
> of the two 32-bit integers contains 32 bits of data and which contains
> 31, but the sign information is stored in the spare 2-byte (short)
> value in the structure.
I have found out the way to deal with int8.
To retrieve the value of a serial8 field, I would use a trigger on the table
containing serial8 field.
insert on table
for each row execute procedure sp_store_serial8(new.serial8fld) ;
create procedure sp_store_seria8(p int8)
define global glb_last_serial_value char(19); let glb_last_serial_value = p ;
end procedure ;
After the insert all we need is to call another stored procdure sp_get_last_serial8()
which will return the value of last serial8 value (the global field) as char(19).
Java programs can directly take char(19) value into a long. ESQL/C will take it as
char(20) host variable and then convert to a long long using atoll() function.
Not 100% elegant, but will work fine. We avoid using ifx_int8_t structure. The problem
with int8_t strucutre is that for all operations, like adding, substracting it has to be
done via functions.
In message <bcn58r$ktbo1$1@ID-75254.news.dfncis.de>, rkusenet
<rkusenet@sympatico.ca> writes
>"Jonathan Leffler" <jleffler@earthlink.net> wrote
>> Right - it isn't documented that ESQL/C understands long long, and it
>> doesn't.
>>
>> > I know int8 in informix is machine independent and is a struct and ESQL/C
>> > is suppose to use that struct. But that would mean a huge change in our
>> > code. So I have written a small function to convert int8 to a long
>> >long value.
>> >
>> > create function biginttochar(p_int8 int8) returning char(19) ;>> > define w char(19);
>> > let w = p_int8 ;
>> > return w ;
>> > end function ;
>> >
>> > In ESQL/C
>> >
>> > $ long myvar ;>> >
>> > $ select biginttochar(fld1)
>> > into :myvar
>> > from ...>> >
>> > works fine till the value of fld1 is 2^31-1 which is 2,147,483,647.
>> > After that it spews error -1215.
>> >
>> > So how to declare a long long int in ESQL/C.
>> >
>> > IDS 9.21.UC4
>> > ESQL: 9.16.UC1
>>
>>
>> You need to upgrade your ESQL/C - not because it provides a solution
>> to the problem, per se, but simply because 9.16 is very old (and 9.21
>> is not very current either - consider an upgrade for that, too).
>>
>> You have to use either ifx_int8_t structures, or you have to use
>> DECIMAL(19) or larger. Both work. You then have to separately write
>> code to stuff that into a long long, or to stuff a long long into the
>> other value. The ifx_int8_t was introduced a year or two before
>> 64-bit integers became ubiquitous. In theory, you should be able to
>> convert an ifx_int8_t into a long long and vice versa with a little
>> bit twiddling. I haven't done the experimentation to find out which
>> of the two 32-bit integers contains 32 bits of data and which contains
>> 31, but the sign information is stored in the spare 2-byte (short)
>> value in the structure.
>
>I have found out the way to deal with int8.
>
>To retrieve the value of a serial8 field, I would use a trigger on the table
>containing serial8 field.
>
>insert on table
>for each row execute procedure sp_store_serial8(new.serial8fld) ;
>
>create procedure sp_store_seria8(p int8)
> define global glb_last_serial_value char(19);> let glb_last_serial_value = p ;
>end procedure ;
>
>After the insert all we need is to call another stored procdure
>sp_get_last_serial8()
>which will return the value of last serial8 value (the global field) as
>char(19).
>
>Java programs can directly take char(19) value into a long. ESQL/C will
>take it as
>char(20) host variable and then convert to a long long using atoll() function.
>
>Not 100% elegant, but will work fine. We avoid using ifx_int8_t
>structure. The problem
>with int8_t strucutre is that for all operations, like adding,
>substracting it has to be
>done via functions.
>
>
>
and it won't necessarily be the serial value corresponding to the insert
done by your program. It may be someone else's....
--
Andrew Lennard andy@kontron.demon.co.uk
"Andy Lennard" <andy@kontron.demon.co.uk> wrote
> >I have found out the way to deal with int8.
> >
> >To retrieve the value of a serial8 field, I would use a trigger on the table
> >containing serial8 field.
> >
> >insert on table
> >for each row execute procedure sp_store_serial8(new.serial8fld) ;
> >
> >create procedure sp_store_seria8(p int8)
> > define global glb_last_serial_value char(19);> > let glb_last_serial_value = p ;
> >end procedure ;
> >
> >After the insert all we need is to call another stored procdure
> >sp_get_last_serial8()
> >which will return the value of last serial8 value (the global field) as
> >char(19).
> >
> >Java programs can directly take char(19) value into a long. ESQL/C will
> >take it as
> >char(20) host variable and then convert to a long long using atoll() function.
> >
> >Not 100% elegant, but will work fine. We avoid using ifx_int8_t
> >structure. The problem
> >with int8_t strucutre is that for all operations, like adding,
> >substracting it has to be
> >done via functions.
> >
> >
> >
>
> and it won't necessarily be the serial value corresponding to the insert
> done by your program. It may be someone else's....
????????.
How is this possible. Please explain.
Ravi
In message <bcn936$kbt9l$1@ID-75254.news.dfncis.de>, rkusenet
<rkusenet@sympatico.ca> writes
>
>"Andy Lennard" <andy@kontron.demon.co.uk> wrote
>
>> >I have found out the way to deal with int8.
>> >
>> >To retrieve the value of a serial8 field, I would use a trigger on the table
>> >containing serial8 field.
>> >
>> >insert on table
>> >for each row execute procedure sp_store_serial8(new.serial8fld) ;
>> >
>> >create procedure sp_store_seria8(p int8)
>> > define global glb_last_serial_value char(19);>> > let glb_last_serial_value = p ;
>> >end procedure ;
>> >
>> >After the insert all we need is to call another stored procdure
>> >sp_get_last_serial8()
>> >which will return the value of last serial8 value (the global field) as
>> >char(19).
>> >
>> >Java programs can directly take char(19) value into a long. ESQL/C will
>> >take it as
>> >char(20) host variable and then convert to a long long using atoll()
>> >function.
>> >
>> >Not 100% elegant, but will work fine. We avoid using ifx_int8_t
>> >structure. The problem
>> >with int8_t strucutre is that for all operations, like adding,
>> >substracting it has to be
>> >done via functions.
>> >
>> >
>> >
>>
>> and it won't necessarily be the serial value corresponding to the insert
>> done by your program. It may be someone else's....
>
>????????.
>How is this possible. Please explain.
>
>Ravi
>
>
Oops! Shows my misunderstanding of GLOBAL doesn't it. Sorry.
--
Andrew Lennard andy@kontron.demon.co.uk