>HI,
>
>I am starting on the long process of documenting of all the existing data in a client's app for the purpose of transitioning it to another system. This will become part of an RFP requirements document. Of course, I would like to not look like a "doorknob" to outside suppliers when they read the document. But I am sometimes at a loss for words for certain items - perhaps those who have done this a lot will know the current terms for these items - I have not had to do this before.
>
>For my table definitions, I was going to have the following columns in the document. Most are straightforward:
>
>Name: column name
>Size/Type: N(5)
>Description: put in to help developer understand the column - NOT going to put a description in for something obvious like "Lastname"

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.

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.