>Hi Peter
>
>>TABLE.iTABLE is always the primary integer key.
>>TABLE.cTABLE is an alternate character key.
>
>TABLE.iTABLE? Isn't that redundant? If you ask me, its not very precise either. Why not TABLE.id and TABLE.name. ACtually as nice in theory as that is, I prefer to do TABLE.id_TBL (Shortened version of TABLE) that way, your relationshipd are easier to match.


Hi, Mike.

Despite being in the same club, we seem to being having communication difficulties. [s]

Now if we are going to have an argument, then you are going to have to come down on one side. I'm going to make that choice for you and assume that you actually do prefer repeating the table name in the key field name despite the annoying redundancy.

Starting the field with "id_" forces you to use a shortened version of the table name. (Unless you use more than 10 characters in the field name, which I avoid, or have very short table names.) Now you have to remember the table name AND the abbreviation. I just have to remember the table name. See the advantage?

>But .name is still a better idea than just renaming it after the table:

EMPLOYEE.Name
ITEMS.Name
MANUFACTURER.Name
SUPPLIER.Name

When I say alternate character key, I'm not talking about a name field. Example, I have a table called ASSOC.


ASSOC.iASSOC 1
ASSOC.cASSOC "SV"
ASSOC.cDesc "Shenandoah Villa"


The name of the association is "Shenandoah Villa" but the character key is "SV". I could use field name "KEY" where YOU used "NAME". I don't do this for the same reasons that we both include the table name in integer key fields: to avoid any inadvertant ambiguity, make relationships clearer, etc.


>>TABLE.dStart instead of TABLE.StartDate
>>TABLE.tStart instead of TABLE.StartDtTim
>
>This I'm not going to touch just because I know its an example off the top of your head :-)

Well, you might as well since I'm completely missing your point. :-)


How's the campaign going?

Peter