Re: Using LIKE to define records in 4GL

In article <3vkdct$ene@nezsdc.fujitsu.co.nz> hugh@nezsdc.fujitsu.co.nz (Hugh Grierson) writes: >In article <3vacu3$4i3@cssun.mathcs.emory.edu>, >Mark Denham <Mark.Denham@bbc.co.uk> wrote: >> I particularly >> dislike [the use of LIKE] in GLOBALS files! > >The only thing worse than LIKE is using a GLOBALS file. >Oh, and using SELECT * INTO record.* > OK, I'll regret this.... I LIKE the record.* syntax. I've been using it since I statred programming in Informix in 1989 and after early on I learned what the pitfalls were, I made sure I didn't get caught. I've built 8 systems so far, totalling (by wc -l) over 500K lines of code. THey're in use in sites scattered around the globe and the users aren't chasing me with bug reports. So the code can't be too bad :) Now the most likely way you'll get into trouble with the .* notation is if your individual table definitions are pretty fluid. I humbly suggest this occurs because of lazy programmers (the let's just add one more column school) and/or poor initial schema design. Followed by lack of testing before release of production code. Recently, I had to interface with a popular Informix accounting app. The invoice header table had 80 columns, at least 70 of which had nothing to do with the invoice header. The designers had obviously never heard of normalisation or the benefits of data partitioning. If this is common practice, then I can understand how people get caught by the RECORD.* notation. But it's their own fault for first doing this sort of schema and secondly for not having a QA team to check the code before release. I add functionality to my systems by adding more *tables* with FK relations, not adding more columns unless it's essential(ie adding an email field to customer). The number of program modules that refer to any one table is small; all do the FK lookup by a single library module. Reports is a bit more tricky but it's unusual for me to use RECORD.* in a report; you're usually playing with the individual data elements anyway. As for GLOBALS, I have exactly *2* files with a GLOBAL def and could get rid of both with minimal effort. I learned programming in BASIC about the dangers of GLOBAL variables. My pet hate is the GOTO statement, which I have NEVER used. Recently had to debug/rewrite someone else's code which was riddled with GOTO statements. Grudgingly, I accept it may have a use in conjunction with WHENEVER ERROR but CALL MyFunc() is far superior. Then there's SCROLL..... Comments ? Peter Wiley