Re: INITIALIZE vs LET

----- 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! Art S. Kagel ----- Original Message ----- From: Mark D Stock <mdstock@mydas.freeserve.co.uk> At: 12/18 17:02 > "Art S. Kagel" wrote: > > > > "Mark D. Stock" wrote: > > > > > > Andrew Hamm wrote: > > > > > > > > Mark D. Stock wrote in message <91bm22$d5p$1@news.xmission.com>... > > > > > > > > > >> > the initialization for the two new columns. I found it when I began > > > > >> > receiving runtime errors (-1210) and also noted the presence of > several > > > > >> > dates of 12/31/1899 (?). > > > > > > > > > >Unfortunately the INITIALIZE command would not have solved this for you. > > > > > > > > Yes it would. a date of 12/31/1899 is a representation of all zero bytes > in > > > > the 4 byte integer used to store dates. Day 1 in the Informix calendar is > > > > 01/01/1900 and this is represented by a long integer value of 1. Hence the > > > > bizarre date when the bytes contain zero. I believe that NULL in all > numeric > > > > types (and dates) is represented by NEGATIVE_MAX_INT - not the proper C > > > > define for that value, but I hope you know what I mean. > > > > > > Actually IIRC a NULL date is 31/12/1899, or in your parlance, 0. > > > > No, 12/31/1899 is NOT the NULL date but the Zero date. If you insert > > "12/31/1899" into a date it does NOT return NULL on SELECT. > > I've never tried that. What I recall is inserting NULL, only to return > 31/12/1899. But perhaps the version I am thinking of has come a long way > since then. > > > > > A defect of 4GL start-up is that all data memory is cleared to zero bytes, > > > > but that means integers and smallints start as 0, chars start as null (I > > > > like that) and decimals also start as null. I think floats start as null > or > > > > is it zero in this circumstance? Dates start as mentioned above - > 31/12/1899 > > > > which is really ugly. The ugly part here is, the logical initial value of > > > > the variables is different depending on the type - inconsistently zero or > > > > null. > > > > > > I presume you mean RDS as opposed to 4GL. RDS very kindly initialises > > > variables for you, 4GL does not. I think an initialised variable of any > > > value is far better than a random memory value. > > > > Actually you are picking nits. C4GL DOES initialize GLOBALS and Module > > scope variables because it is "C" based the linker will initialize GLOBAL > > memory to zeros. Global memory is also where module or file scope variables > > are stored so they are initialized also. It is only function scope variables > > including MAIN program vars that are garbage because they are defined on the > > program stack and contain whatever was on the stack. > > I wasn't meaning to. The version of C4GL we used (yes yes, probably > version 4 or less) didn't initialise any variables for you. That was one > advantage, among many others, of sticking with RDS. > > > > > Dammit, I hope I haven't provoked a fresh, endless dialog on the subject. > > > > > > Well...., fresh for these times, but not endless. Oh, and my name isn't > > > Dammit. ;-) > > > > > > > <someone said> > > > > >It could be that these messages have only just appeared on the list for > > > > >some strange reason, or it could just be that no one uses 4GL anymore. > > > > >;-) > > > > > > > > I wish... > > > > > > You mean you wish people wouldn't use 4GL any more? Why? Once you've > > > used the best, the rest are the rest. :-) > > > > AA AA AA AAMen > > I can't fix that stutter....., but I know a man who can.... :-) > > Cheers, > -- > Mark. > > +----------------------------------------------------------+-----------+ > | Mark D. Stock mailto:mdstock@mydas.freeserve.co.uk |//////// /| > | http://www.informix.com http://www.informixhandbook.com |///// / //| > | http://www.iiug.org +-----------------------------------+//// / ///| > | |This email will self-destruct in |/// / ////| > | |10 sec. If you received this email |// / /////| > | |in error, sorry about the mess. |/ ////////| > +----------------------+-----------------------------------+-----------+

"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). -- 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!"

In article <3A3FB7A0.16C5DA5E@informix.com>, Jonathan Leffler <jleffler@informix.com> 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). > > -- > 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!" > Why _must_ the previous value in the variable be overwritten? From 9.2 Syntax guide p. 2-426 -- You cannot select a null value from a table column and place that value into an output variable. If you know in advance that a table column contains a null value, after you select the data, check the indicator variable that is associated with the column to determine if the value is null. -- To me this implies that if a null value is selected, what is contained in the variable holder is undefined, only what is contained in the indicator holder is defined. What is actually the case is not something I can't test seeing I do not have 4gl. If what is in the variable defines whether or not something is NULL, why have the INDICATOR at all? Will Sent via Deja.com http://www.deja.com/

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. Art S. Kagel