>>last and saves, other user may have gotten the same key from the key >>offering routine; the third and fourth got another ones. Now the first >>three users revert and don't save - I have three unused keys. I don't >>mind, but tax collectors are very suspicious if the invoice numbers are >>not exactly consecutive. >> >>Did anyone solve this problem already? .... >arguably become a meaningful key and is no longer a surrogate. If they >have to be consecutive, meaning of a sort has already been imposed. One of >Robert Keith's threads discussed the question of how to reuse key values. The idea just came to me as I was reading this - there can be couple of records in the Uniq_ID.dbf, for all the keys which are reserved for an user, with a master record keeping the last value written, and others keeping the values reserved. So if an user doesn't save, some flag on the record marks the key as unused, so the new_key() routine will supply one of them, otherwise (I'm programming it in my head as I write this...) Now that's it: a record in the uniq_id.dbf can have next status options: 1. it's the "last saved" value, meaning there are no other records for this key 2. it's reserved - given to the user, and the user is still online, having not decided to save or drop yet 3. it's dropped and thus reusable 4. it's used and should be saved to the last_saved record, unless there are no keys of the 2. or 3. type between it and the last_saved one. This could keep track of keys given, used, dropped etc. Sounds a bit complicated, blanking the records when the situation gets back to normal, needs reusing blanked records, but I think this will be the solution. >I network the stuff, the RI better work, and Barbara says I shouldn't count >on RI to cascade all changes. Now that I'm linking in still more tables, >and overhauling other stuff, I'm starting to make surrogate keys. What does she mean "don't count on RI" - the wizard-generated stuff or any RI stuff in general? Is it possible it doesn't fire always, or what? Barbara?