Re: Setting database at runtime with 4GL

> > > Now the advice: > > You only need the declarative DATABASE statement in your 4GL source if you > > use the syntax "DEFINE program_something LIKE db_something". ... <snip> > > ... In general, I recommend against using the declarative form. > > *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. 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. cheers j. _____________________________________________________________________________ Jack Parker - Hewlett Packard, BSMC Boise, Idaho, USA jparker@hpbs3645.boi.hp.com _____________________________________________________________________________ Windows/NT - from the people who brought you edlin. _____________________________________________________________________________ Any opinions expressed herein are my own and not those of my employers. _____________________________________________________________________________