>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.
>
>Does anyone have any experience in using this naming approach?

This was the old standard for large scale systems. I liked the idea because the output as displayed in a query would never have KEY_A, CUSTNO_B.

Those are necessary for having the key in each table for updating.

Other people have done XXAYYYYY XX as table, A Atribute, YYYYY as field deecription.

Proper Capitialization is needed to see
cu_Address as cuCaddr1

This helps in joing a numeric value to a character, or better yet, a date as character! {Y2K Lives}.