Using RECORD LIKE, SELECT *, etc.

Kerry Sainsbury wrote: } > } > *Why* do you recommend against DEFINEing LIKE database items? } > } > I've found it to be utterly invaluable when a new client decides they } > need to (say) hold quantities to 3 decimal places, or support 20 character } > product codes, or whatever other requirement they have. } > } > Simply recompiling the source (and maybe editing some forms) is *much* } > nicer than having to search your code for all declarations of variables } > that are used to hold the changed data. Jack Parker wrote: } } Sound words. Allow me to represent the opposing argument. } } You have 1000+ source files - some of them you no longer remember what they } do much less what sort of storage they needed to do it in. Or the original } programmer has gone south for the winter - whatever. You're preparing a } new release of your software which includes a schema change and somebody } DEFINED LIKE someplace where it was perhaps not exactly appropriate. Since } you don't realize that this entire module has been affected, it, and 300 } others, don't get much exhaustive testing..... Say no more. } } For this reason we tend to stay away from some of 4GLs nice features like } RECORD LIKE and SELECT * or INSERT INTO table VALUES (record.*). I remember } cursing this rule quite soundly and on the sly went and changed a copy } program which employed something of this nature. When it bit me I not only } turned red, but I caused a lot of problems in production. } } I managed to invent a work around for that one piece of code so that it doesn't } need changing every time we do a schema change (in fact I'd have to look now to } see a) what the logic was that I used b) why I didn't just select * into a } temp table and then pop it back in), but I now think very carefully about how } I use LIKE and such. Alan Popiel writes: Every tool has its uses, and a tool's dangers are usually proportional to its power. After all, you can cut more firewood faster with a chainsaw than with an axe, but improperly used the chainsaw can injure you worse than an axe. We are in the process of building a configuration database for our software. A major feature will be dependency information. We hope to capture dependencies down to the table level. It will NOT be a lot of fun finding and recording all this stuff, not to mention browbeating people to keep it up to date. However, such a database, if well maintained, would solve some of the problems with Jack's 1000+ source files. If you need to change a table, just run a query to find out which sources, executables, scripts, etc., will be affected. You either know what to change and/or recompile, or you find it would be such a pain that you might try an approach that does not require changing THAT particular table. Regards, Alan +---------------------------+-----------------------------------------------+ | R. Alan Popiel | Internet: alan@den.mmc.com | | Martin Marietta, SLS | Voice: 303-977-9998 | | P.O. Box 179, M/S 3810 | Standard disclaimers apply. Cutesy ones, too. | | Denver, CO 80201-0179 USA | Your mileage may vary. Void where prohibited. | +---------------------------+-----------------------------------------------+