Re: INITIALIZE vs LET

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. > 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. > Hence, using INITIALIZE, which does the hard work of getting all fields to > their proper NULL value, is definitely a good idea. Jonathan was talking > about using one INITIALIZE X.* as opposed to the use of 50 LET statements > which can get "left behind" in the face of schema and software changes. > Thus, INITIALIZE X.* is safer to use in the sense that it adapts to new > schemas - as long as you at least blindly recompile the 4GL. True, but the question was about performance, which was where the dummy record came in. If you have adopted the .* notation throughout your code, then the new columns will certainly get included at the next compile, but they won't be used until you change the code. > Regarding performance: I'm not surprised when Jonathan claims it used to be > a hot topic, because people get really fussy about performance to the Nth > degree. But why? Because when using a very flexible development tool like 4GL, you can get very differing performance levels, depending on how you code. So there is a lot to be gained in coding for performance with 4GL. > Once you get your variables initialised, you are about to > trigger potentially thousands of disk reads and writes. Where is your > efficiency now? Nowhere, if you are hitting disk to that extent. You should do some application tuning and get some of that processing into memory. The cost is memory, the gain is performance. IO is the biggest bottleneck in any database application. > 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. :-) 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. |/ ////////| +----------------------+-----------------------------------+-----------+

"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. > > 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. > > Hence, using INITIALIZE, which does the hard work of getting all fields to > > their proper NULL value, is definitely a good idea. Jonathan was talking > > about using one INITIALIZE X.* as opposed to the use of 50 LET statements > > which can get "left behind" in the face of schema and software changes. > > Thus, INITIALIZE X.* is safer to use in the sense that it adapts to new > > schemas - as long as you at least blindly recompile the 4GL. > > True, but the question was about performance, which was where the dummy > record came in. If you have adopted the .* notation throughout your > code, then the new columns will certainly get included at the next > compile, but they won't be used until you change the code. > > > Regarding performance: I'm not surprised when Jonathan claims it used to be > > a hot topic, because people get really fussy about performance to the Nth > > degree. But why? > > Because when using a very flexible development tool like 4GL, you can > get very differing performance levels, depending on how you code. So > there is a lot to be gained in coding for performance with 4GL. > > > Once you get your variables initialised, you are about to > > trigger potentially thousands of disk reads and writes. Where is your > > efficiency now? > > Nowhere, if you are hitting disk to that extent. You should do some > application tuning and get some of that processing into memory. The cost > is memory, the gain is performance. IO is the biggest bottleneck in any > database application. > > > 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 Art S. Kagel