SQL: using the newly inserted index as a value for insertion

David Glass dglass at graymattercomputing.com
Mon Nov 25 05:04:32 CET 2013


If you work to make sure the keys are unique then the risk of collision 
should be minimal.

A date stamp down to the second (with all the special bits stripped) 
with microseconds tacked on the end, and an identifier based on user 
login, or machine id, or whatever you have available seems like it would 
be workable.


> That opens bigger cans of worms :)
>
> The presumption is simultaneous users with periodic updates (the lag stops
> me from doing them real time, so I store in memory until synchronization
> when no keystrokes for a while).  If Jane enters a new record on her
> machine, and Wendy a new record on hers, local assignment would give them
> both the same key, at which point I have to deal with *that* when the
> second one trys to sync . . . so they keep a temporary id in memory, and
> the same transaction that inserts to the table finds the new record and
> brings it back.



More information about the use-livecode mailing list