[AccessD] Primary Key Best Practices

John Bartow john at winhaven.net
Wed Jul 25 11:10:38 CDT 2007


LOL!

I actually have the same view on PK but have recently had to expose PKs in
an application for a client. (Well, I suppose I could have told them NO but
then I'd probably not still be working for them.)

They implemented a new functionality in their GIS system. Instead of paying
me to implement it correctly, they tried to have "local" firm implement the
GIS (spatial) portion and retain me to do the "tabular" portion. (The whole
thing is ridiculous but when you do government work you come to expect
this.) Anyway, I had to expose the PK of certain tables in the interface
because the "local" firm apparently doesn't know how to connect to an mdb in
order to pull up a combo box in for the staff to choose from. Hence the
staff is manually entering the PK to connect the spatial elements to the
tabular elements. Wrought with danger is all I can say. I don't think the
local firm is working there anymore - so hopefully I get to fix this mess
some day }:-p

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby

It comes from discussions here on this list where any time you expose the PK
to view, some idiot wants to use it for some purpose that it is not supposed
to be used for (like a "must be in order, with no values missing" number in
an accounting system.  Obviously we can and do delete records all the time
so using the PK for such a rule / purpose guarantees issues whenever the
idiot strikes, thus simply NEVER expose it to view.  

The PK's function (in real life) is exactly and only for use as a pointer
from a child back to the parent.  




More information about the AccessD mailing list