4gl and NULL integers with 7.30.UC1

Hi, We are migrating our 4gl code to 7.30.UC1 (IDS2000 v9.21FC2). During the tests we came across the following new feature. You can no longer let an integer field be set to NULL by using the "" you must use the value NULL or null. A 4gl line might be like LET code1 = "" to set code1 to a null. However, what happens with c4gl 7.30UC1 code1 gets set to -2147483648 which exceeds integer precision and causes the insert or update to error. Here is a test 4gl program to illustrate what I mean. #testnull.4gl globals define r_test RECORD empl_no integer, home_text char(16), code1 integer, code2 integer END RECORD end globals main database whatever Create temp table temptab (empl_no integer, home_text char(16), code1 integer, code2 integer))let r_test.empl_no = 1 let r_test.home_text = "TEST" let r_test.code1 = NULL let r_test.code2 = "" display "r_test.code1=",r_test.code1 display "r_test.code2=",r_test.code2 insert into temptab values (r_test.*) end main Here are the results of the above program running (IDS2000 v9.21FC2) - 4GL 7.30.UC1 - on DEC alpha2100 TruUnix64 v4.0F testnull.4ge r_test.code1= r_test.code2=-2147483648 Program stopped at "testnull.4gl", line number 25. FORMS statement error number -1215. Value exceeds limit of INTEGER precision With the help of awk and gsub the code our 4gl code has been modified to meet this new standard. Walter R. Guertin, Jr. Production and Development Manager City Of Worcester - Information Services Department Tel. (508)-799-1272

"Guertin, Walter" wrote: > We are migrating our 4gl code to 7.30.UC1 (IDS2000 v9.21FC2). > During the tests we came across the following new feature. > > You can no longer let an integer field be set to NULL by using the "" > you must use the value NULL or null. Well, using the character string is a dubious way of writing NULL. I'm not sure I approve of it at all. > A 4gl line might be like > LET code1 = "" > to set code1 to a null. > > However, what happens with c4gl 7.30UC1 code1 gets set to -2147483648 Which is the internal code for NULL. > which exceeds integer precision and causes > the insert or update to error. So there's something funny going on. > Here is a test 4gl program to illustrate what I mean. > > #testnull.4gl > globals > define r_test RECORD > empl_no integer, > home_text char(16), > code1 integer, > code2 integer > END RECORD > end globals > main > database whatever > Create temp table temptab > (empl_no integer, > home_text char(16), > code1 integer, > code2 integer))> let r_test.empl_no = 1 > let r_test.home_text = "TEST" > let r_test.code1 = NULL > let r_test.code2 = "" > display "r_test.code1=",r_test.code1 > display "r_test.code2=",r_test.code2 > insert into temptab values (r_test.*) > end main> > Here are the results of the above program running > (IDS2000 v9.21FC2) - 4GL 7.30.UC1 - on DEC alpha2100 TruUnix64 v4.0F Oh, DEC Alpha. 64-bit. Ugh! Or, rather, it's a very nice machine, but it can cause problems... > testnull.4ge > r_test.code1= > r_test.code2=-2147483648 > Program stopped at "testnull.4gl", line number 25. > FORMS statement error number -1215. > Value exceeds limit of INTEGER precision I suspect you've hit a bug in the way I4GL handles 32-bit INTEGER variables with DEC 64-bit longs. You could probably report it to Informix Tech Support. I'm not 100% sure what they'd recommend as a workaround, but... > With the help of awk and gsub the code our 4gl code has been modified to > meet this new standard. ...this sounds plausible. I think you are better off assigning NULL than "" to anything except (perhaps) a string variable. It worked OK with some prior version of I4GL? On the DEC Alpha? The big change between 7.20 and 7.30 was the move from ESQL/C 7.24 to CSDK 2.30 or ESQL/C 9.20. And one of the changes made between ESQL/C 7.24 and CSDK 2.30 was the addition of data types like int4. I suspect we're running foul of some mismatch between I4GL and CSDK on the 64-bit platforms. > Walter R. Guertin, Jr. > Production and Development Manager > City Of Worcester - Information Services Department > Tel. (508)-799-1272 -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"

Jonathan Leffler wrote in message <3A415379.D76BA73C@informix.com>... > >Well, using the character string is a dubious way of writing NULL. I'm >not sure I approve of it at all. > Dubious or not, there are odd locations where you CANNOT use null. Try this (don't know if 7.3X is fixed) return NULL and you get a stupid error message about NULL being an undefined variable. | The symbol "null" does not represent a defined variable. | See error number -4369. Function call is also bad news: call x(NULL) with the same compiler error result. There are one or two more situations (can't recall them off the top of my head, or the sides) where "" must be used instead of NULL, which is kinda irritating. Regardless of this, although it may rightly be called "dubious" it is nevertheless correct since 4GL (RDS or C) supports conversion of string to numeric, and thus any kinda null string should be correctly converted to it's equivalent null numeric. signed: Andrew "with the occasional dubious programming practice" Hamm.

"Guertin, Walter" <GuertinW@ci.worcester.ma.us> writes: > A 4gl line might be like > LET code1 = "" > to set code1 to a null. What's wrong with using: INITIALIZE code1 TO NULL hmmm? And it's documented, too!! Stick with documented features and you're less likely to be surprised during an upgrade. -- Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412 Ronald Cole <ronald@forte-intl.com> Phone: (760) 499-9142 President, CEO Fax: (760) 499-9152 My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B