This is a question about the likelihood of multiple users perhaps conflicting while attempting to generate new records containing a unique value for the record which is not the key ID (which is already a UUID).
In this application I am generating some unique, composite alphanumeric IDs which therefore need to be built with a script at the time of record creation. They follow a logical sequence.
By the time the script has executed, it’s conceivable that the next valid computed value had already been assigned and therefore would not be unique. I might be able to trap the 504 error and try again in this unlikely event but how far to go?
The same sort of question might be raised for generating a simple, incrementing numeric ID. Initially it looks trivial, just set an auto-enter counter to assign a value on commit and FM will robustly apply it.
However, the counter needs management after import operations, deletions etc. which needs a script to reset it. My technique in this instance is to get the maximum value from the found set (or the found and omitted set, choosing the higher).
So why use a counter at all? Why not just use this script to determine what the next value should be and assign it directly when a new record is created? It’s self-correcting, fast and, so far in a single-user situation, always generates a good value no matter the state of the data.
The answer again depends on whether a conflict could occur when multiple users are creating new records.
How does FM queue new record requests in a multi-user environment? Or are they executed in parallel?
What is the best practice or am I worrying about nothing?