Jim,

My method for covering all this is simple.

First - I only use surrogate (integer) keys. Now, let's say I have a customer table with the two letter code "cs" and an invoice table with "iv". My pkey in customer will be named "cs_key", my pkey in invoice, "iv_key", and the fkey in invoices pointing to customers will be named iv_cskey. this accomplishes all the following:

1) it is very clear what is a key because of the word 'key' in it
2) it is easy to distinguish between pkey and fkey (pkeys are always of the form "xx_key" ..... fkeys always "xx_yykey" )
3) you can easily see in an fkey field's name, both the table it is in and the parent table it is related to
4) It makes it great in joins not to have to waste space or time typing alias names - very clear and quick to do "join on iv_cskey = cs_key"
5) It is also great not to ever have to wonder "what the name of that darn field is" to do joins, etc.
6) It is consistent and follows the overall convention

As far as the overall convention, some additional benefits are:

1) you never have to wonder whether a word is a field or not - combined with good variable naming convention, ie "lcName" for local, character, name variable for example, it makes it real easy to know what's what in the program.

2) you don't have to worry about using VFP reserved or key words. (shouldn't name a field "select" but "cs_select" works great and retains best meaning if best meaning happens to be a reserved word)

I think this is a great naming convention. It may be old fashioned (Goerge Goley was first I ever saw that promoted it back when), but it by far the clearest I have ever seen or used. "Plain" naming systems ( I have worked with) I have found to be much more confusing and tedious to work with.

Now - one possible caveat. John K. says there may be a problem with underscores in SQL Server. I have not yet had any problem, but I've just been working with SQL for about two weeks now. Hopefully, I can continue to use this convention.

Thanks!
Ken

>Folks,
>
>Just to add my two cents in here. I don't use the two char prefix on table field names. My primary reason is trelated to PK and FK situations. I believe that if there arte two fields that share the same domain they should have the same name. A PK and FK by definition share the same domain, therefore they should have the same name. Using table prefixes precludes the two from having the same name.
>
>Taking that position a step further, if some of the fields don't follow the prefix convention then that convention is not being used conssitently. A convention that is not used consistently is not very valuable.