INITIALIZE vs LET

Version: 7.31 OS: AIX 4.3.3 I know the FAQ and the 4GL Reference indicate that initializing each field within a record with LET is preferable to using an INITIALIZE record.* but I have run across a situation that would seem to indicate the use of the INITIALIZE approach even if less efficient: In a production system, one of the main tables had two date columns added (with nulls allowed). There was no problem until on of the programs referenced this table containing a "working storage" image of the table (work LIKE record.*). This program initialized each field (column) using LET statements BUT no one had added 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 (?). At first I added two more LET statements but then thought the better solution would be to precede the initialization with an INITIALIZE record.* to NULL. I confess I am new to Informix and Informix 4GL (though not to RDBMS and 4GLs). Would anyone care to comment on my situation and conclusions? Thank you, Lucky Lucky Leavell Phone: (800) 481-2393 or (812) 366-4066 UniXpress - Your Source for SCO FAX: (888) 231-9640 or (812) 366-3618 1560 Zoar Church Road NE Email: lucky@UniXpress.com Corydon, IN 47112-7374 WWW Home Page: http://www.UniXpress.com

"Lucky Leavell [RIS]" wrote: > > Version: 7.31 > OS: AIX 4.3.3 > > I know the FAQ and the 4GL Reference indicate that initializing each field > within a record with LET is preferable to using an INITIALIZE record.* but > I have run across a situation that would seem to indicate the use of the > INITIALIZE approach even if less efficient: In a production system, one of > the main tables had two date columns added (with nulls allowed). There was > no problem until on of the programs referenced this table containing a > "working storage" image of the table (work LIKE record.*). This program > initialized each field (column) using LET statements BUT no one had added > 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 (?). > > At first I added two more LET statements but then thought the better > solution would be to precede the initialization with an INITIALIZE > record.* to NULL. > > I confess I am new to Informix and Informix 4GL (though not to RDBMS and > 4GLs). Would anyone care to comment on my situation and conclusions? Five years ago, this would have started a huge debate. In fact, if you found suitably ancient archives, you could probably find several versions of those debates. The use of INITIALIZE versus LET is a pure performance issue; it is not actually all that critical unless you do an awful lot of INITIALIZE work. INITIALIZE LIKE is much harder on the system; it goes to the syscolval or syscolatt table (if you've used UPSCOL) and digs out defaults from there. Ugh. The more complex and controversial issue is the use of RECORD LIKE Table.*. It has merits; it has demerits. Merits are that most of the code adapts to the appearance of new fields in the tables, and the code is more succinct. The demerits are that there are enough places where the code does not adapt to the new fields to make adding fields problematic - witness your problem (and also screen records in forms, and therefore the INPUT statements that use them). So, there's a strong argument for using explicitly defined record structures citing exactly the columns you intend to work with. New columns don't cause trouble unless they won't accept nulls, or you cut corners (eg by forgetting to list the columns in an INSERT statement). Speaking personally, I've always used the RECORD LIKE Table.* notation and found it too valuable to do without. I have even gone to the extent of creating empty tables in the database to define convenient record types so I can use RECORD LIKE Table.* notation in multiple files, rather than having to worry about synchronizing complex record definitions across files. That is more an indictment of I4GL than anything else; there is no mechanism that allows you to define types other than this one. However, there are several people who still lurk on this news group who would probably regard that as anathema, so maybe they'll give you their version of the truth (I've tried to represent it, but I undoubtedly failed to express all the demerits fully). -- 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!"