Maybe it's different for different applications (in the big sense of that word), but I couldn't ever imagine letting users directly at tables or see field names directly. Must be a side-effect of my little "vertical market app" world.

If Idid have a need to let users direclty at it, I certainly wouldn't want one to get at it whose brain got scrambled from a two letter prefix!

my 2E-2

Ken

>>In my reading I came across a convention for namining fields in a table that used a 2 letter table identifier followd by an underbar as a prefix to all table field names.
>>For example in a Customer table une would finf fields:
>>cu_CustCode
>>cu_Address
>>cu_City
>>cu_State
>>
>>etc. Each table had its fields specified in this manner.
>>
>>It is clear that there are advantages to this nomenclature in that you can easily identify and distinguish a field in a table from memory variable. There are also advantages in SQL statements.
>>
>>Doing it however is somewhat of a pain and I am wondering if it is worth the effort.
>
>There's another potential problem with a convention like that, and one reason I wouldn't use it (besides being a bit of a pain). We have vfp, sybase, sql server, and access data all available through ODBC to various sources, and end users have direct contact with field names. Users are already confused enough without having to deal with prefix jargon such as that above. Of course, if your field names will never see the light of day, that's a different story...