Gerry,

I really agree with your comment about searching through the code. If you have a field named just "id", there is essentially no way to search through your code for it. If you have a small project, that is fine. We have a really large project and field names that are short or are common letter groupings such as "id" are basically impossible to search for because you get too many matches with other words.

Jonathan

>>I have been using the following convention for field naming in tables:
>>
>>TRANSACTION.DBF
>>
>>tr_id I(4)
>>tr_code C(10)
>>tr_dtime DATETIME
>>tr_exported L(1)
>>tr_cl_id I(4) (FK from client table)
>>tr_pr_id I(4) (FK form products table)
>
>I use the "old" convention; except, no underscores and my "field prefix" is 3 chars.
>
>I also have about 200 tables, 4000 fields, 2000 programs, and 350,000 lines of code to maintain.
>
>So ... when I'm trying to find where the field CLMNAME (ie. Client-Master Name) is being referenced, I can search across files and directories using my text search utility and find ONLY those programs and statements where CLMNAME is used, and not every occurance of NAME, name, xxxNAMExx or whatever. You also won't get any "collisions" SCATTERing. You also have a unique key for any "data dictionary" vs having to know all the table(s) for every non-unique Field Name. And a table name/alias can be inferred from the "Field Prefix", making for "smarter" apps.
>
>If one only writes trivial apps, then all this is "BS" (as someone put it), otherwise it might help you keep your sanity.
>
>And, adding a "type" to a "Field Name" (eg. cName, dDate, nCost), is THE ultimate BS (IMO) ... since most field names are self-explanatory, already "documented" in the DBF structure, and are a pain to change (name-wise) if you decide to change the "type" (eg. from say "numeric" to "currency" or "binary") ... in which case you probably wouldn't bother changing the name, and consequently the "standard" is kaput.