> > What a field name represents is a matter of perspective. A PK in a company table is not the same as a PK in an invoice table. Should they both be called PK? EmployeeID in two different tables may be what you are referring to, but there is no harm in Sal_EmpID for the sales table representation of employee versus Emp_ID in the employee table. I've done both and don't see there is much different between the two except that I rather like not getting my hands slapped by the computer when I don't add the alias prefix.
> >
>
> My practice is to iID for every PK, but I recognize that others may do something different.
>
> Far more important, though, is that if you have a field for, say, date sold, and it's dSold in one table, it should be dSold in any other table that has the same concept. I'm working with an application now where the original developer tried to make every field name unique (without using a convention like yours) and it's murder trying to figure out which fields represent the same concepts and which don't. (The fact that the data isn't properly normalized is just an extra added attraction.)
>
> Tamar

I agree completely with this. There has to be consistency across same fields or it can cause havoc trying to find the correct table a field comes from or what exactly a field stores if it stores the same value but is called differently in each table.

Bernard

** If you see someone without a smile, give em one of yours :) **