Re: INITIALIZE vs LET

On Wed, 20 Dec 2000, Art S. Kagel wrote: >Jonathan Leffler wrote: >> "ART KAGEL, BLOOMBERG/ NEW YORK" wrote: >> > ----- Original Message ----- >> > To: mdstock@mydas.freeserve.co.uk >> > At: 12/18 17:13 >> > >> > What likely happened is that you FETCHED the date into a GLOBAL which is >> > initialized to zero (ie 12/31/1899) (or a local in R4GL). Since the column >> > was NULL the FETCH did not alter the current contents of the variable so it >> > remained zero! >> >> Surely not? If you fetch a null value, then the previous value in the >> variable must be overwritten to indicate that the fetched value is now >> null. Only if there was no data to fetch or an error occurred would the >> variable be unaltered (and it might have been altered if an error >> occurred). > >It's been a long time since I did serious 4GL, but in the underlying ESQL/C >FETCHing a NULL into a host variable does NOT alter its contents from before >the FETCH, you have to use an indicator variable to detect that it has had >a NULL fetched into it unless you are cagey and initialize the var to an >impossible value and check to see that it was not overwritten from that >value. If 4GL is checking the indicator and overwriting the garbage in the >DATETIME variable with a NULL DATETIME that's another story. OK, you're the second person to assert something along those lines to me today, in the context of this thread. So, I went to do some checking to provide proof by (counter-)example: $ cat xx.ec #include <stdio.h> int main(void) { EXEC SQL BEGIN DECLARE SECTION; int j = 0; EXEC SQL END DECLARE SECTION; EXEC SQL WHENEVER ERROR STOP; EXEC SQL CONNECT TO 'stores'; EXEC SQL CREATE TEMP TABLE T(I INTEGER); EXEC SQL INSERT INTO T VALUES(NULL); printf("Before SELECT: %d\\n", j); EXEC SQL SELECT I INTO :j FROM T; printf("After SELECT: %d\\n", j); EXEC SQL DISCONNECT ALL; return 0; } $ rmk -u xx INFORMIXC="gcc" esql -O xx.ec -o xx rm -f xx.[co] $ ./xxBefore SELECT: 0 After SELECT: -2147483648 $ It looks to me as if using my current version of ESQL/C (this happens to be ESQL/C 9.40.UC2, from CSDK 2.50.UC2, running on Solaris 7 against a Foundation 2000 database version 9.21.UC1), the variable is set. Now, if there is somewhere in the manuals that asserts that this should not happen, we have a bug -- probably a documentation bug. I vaguely remember what you state being what happened some very long time ago, and indicator variables are certainly more reliable than inspecting the value, but that value is the only 32-bit 2's-complement signed integer value that is not also a valid value in the Informix database. It has the hex representation 0x80000000, and that is used to indicate a null INTEGER. -- 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!"