>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...