>I was doing this on last few projects, and generally the rule is that the more obvious the name, the shorter the description. In case of the first-last-middle-DoB and such fields, no description. But for foreign keys, "fk into othertable.keyfield". For fields containing magical numbers, list them (e.g. "0 - none, 1 - some, 2 - many, 3 - too many"), for fields with a short list of string values, list them ("blue", "red", "neutral gray", "aggressive gray", "white",...). For fields which are a fk into a list-of-lists table, specify which list.

and "passive gray" and "passive-aggressive gray"...

>Most important: write all these inside the database itself. The comments field of the table structure (regardless of whether it's a dbc or SQL or whatever, there's always such a text field). Then your documentation stays with the table, and the programmers who may use it don't have to ask for documentation, it's contained within. And it's easy to write a generator for the documentation once you have the descriptions in the comments - I remember I wrote it in .rtf format in FPD2.6, then Word in VFP6 and finally in html.

unfortunately, a lot of free tables in this app (not all but most) so no comments area...app originally written in FPD2.6 and never went through the pain of converting the tables (in reality, I was not sure what the framework I was using was doing with certain things and it was just easier to stay with the free tables until much later on I started to dabble with them).

Albert