Ed Leafe wrote: > On Jan 22, 2007, at 2:15 PM, Carl Karsten wrote: > >> I'm not sure I can even code it outside. I am starting to think >> compound keys >> have to be natural keys, as in "input by the user" or some outside >> source, which >> is taken care of by the app or some layer above the data tier, and >> completely >> avoids the code that would be needed to deal with server side. > > No, not at all. It could be as simple as Invoice Number + location, > where the invoice number is generated at each site.
So "location" is the same value for all records on any one server? and the Invoice number is unique. I guess that is server generated. Definitely something I hadn't thought of. So it is a compound key if you start mixing data from other systems. > It could be two > completely random-type numbers, or a sequential value plus a hashed > value. It could be a guid and 5 nulls fields. not sure that qualifies. > > Aren't most GUID algorithms based on several values whose bits are > then joined? Even though it's stored in a single database column, > conceptually it's a compound key. guids are basically a machineID + time stamp. so much like your InvoiceNo+Location, the machineID would be a constant, and the time stamp the uique part. I think you have demonstrated something that a) could be realistically implemented and b) dabo can't handle, which is about as much interest as I have. weather or not it is truely a compound key can be figured out some other time. Carl K _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
