[EMAIL PROTECTED] wrote: > Carl, > 1) The pk field is a postgres serial type. I assume that there is code in > dabo to fetch the new pk value via a nextval() pass-through function. > > 2) Because the design specs call for it.
So chnage it :) or does someone have a use for it? perhaps the right way to phrase my question is "What is the use case for embedding the PK in that ID?" > What problem do you see with this? It is more work to write, debug and maintain. It sounds like it is going to be an extra hit on the server for each save (save, get PK, update ID) which means for a short period, the ID will be... blank? which means you can't have a db rule to enforce the uniqueness, unless you add a special case for blank, which is even more work, debug, maintain.) It goes against the "only store data in once place" rule of normalization (you are storing the same data in 2 fields.) you can address this if you break the ID field into 2 parts (yy and xxx-xxx-xx) and then construct it when the data is retrieved: select yy + pk + xxx-xxx-xx as ID... Someone may be expecting to use the PK to look for gaps in a sequence (like check numbers or transaction numbers) they may need to adjust the counter or something. I am sure you 'can' use the server's PK counter for this, but using the PK as business data is generally a bad idea. Carl K _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
