Re: Using LIKE to define records in 4GL

jparker@hpbs3645.boi.hp.com (Jack Parker) nattered on and on about: >> Are there other difficulties I should be aware of? Fourgen uses this >> construct heavily in their program generator. >The biggest problem, with it is in a maintenance situation. >Here check it out. >CREATE table tab ( > a char(1), > b char(1), > c char(1)) >DEFINE abc RECORD LIKE tab.* ># So abc looks like: > abc.a, abc.b, abc.c >..... >SELECT * FROM tab INTO abc.*>.... >compile 4gl code.... >ALTER TABLE tab ADD COLUMN d char(1) BEFORE column b >run 4gl code.... (compiled on old schema) >Your cursor is now doing: > SELECT a, d, b, c > INTO abc.a, abc.b, abc.c >If you have made a habit of this, that's a lot of places to track it down >and fix (at very least by recompiling). >If you did >DEFINE abc RECORD > a char(1), > b char(1), > c char(1) >AND your select statement did: >SELECT a, b, c FROM tab INTO abc.* >Then you are insulated - no matter what new columns are added your code will >still work the way it was intended. Very true, but it usually is just a case of a recompile. This is obviously a problem in a mission-critical situation where it requires scheduling some downtime to roll out the updates to the programs. But, if the column(s) added are essential to the application anyway, how are you helping yourself? They need the new program to process the new or different information that is provided. Even though I make far too many changes because of insufficient modeling analysis, many of them are legitimate changes to the business process or the incoming/outgoing information. There's nothing one can do to eliminate these, and in such circumstances, I find it easier to simply change the code which actually handles the information, rather than having to find all my record definitions and modify them as well.