Using RECORD LIKE, SELECT *, etc.

> > 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. What we use is an find/grep shell searcher. Once we have determined that a schema change or whatnot is necessary, we use this shell to scan ALL of the source and return a list of filenames and the associated text. Then we check each occurence. It's not as nice as a configuration database, but since it requires no updating, other than the source being in the right location, it has a chance of success. Needless to say we also have a utility to check that all source is in the right place - that there are no executables that cannot be made from the existing source, that the makefile knows how to make each executable, and that all makefile entries are locateable in the source tree. But then this is a whole other topic - and we have a bunch of other utilities to deal with it (what's checked out - what has changed for thsi release... ad nauseum). I tried once to load data 'to be maintained' in a database, but the best of intentions.... It never got updated. As 'engineers' it is in our best interest to lower the level of buraucracy (sp?) on each of us - therefore all of our utilities (save one - task management) use the source tree for data. I mean no disrespect Alan, but unless you've got the guns to back up such an effort, and the thick skin to endure the ire of your peers... I remember hearing an estimate, back in the my consulting days, that an engineer managed to spend 20% of their time into actual engineering and the other 80% was spent in administrivia. I therefore suggest an approach that does not add to the 80% portion of the workload. cheers j. _____________________________________________________________________________ Jack Parker - Hewlett Packard, BSMC Boise, Idaho, USA jparker@hpbs3645.boi.hp.com _____________________________________________________________________________ He who lives by the keyboard, dies by the keyboard. >thud< _____________________________________________________________________________ Any opinions expressed herein are my own and not those of my employers. _____________________________________________________________________________