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.