Hi Jacob,

My vote would be to keep away from *any* naming "convention" for field names.

There will be instances where the field name will become a column heading name, and this can add to 'confusion' of users.

By all means I *would* use a naming convention for almost anything that a user is not going to see, including PK or FK in TAG names.

regards,

Jim n

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