My FMServer served multi-user database has a need for generating a new unique serial number for the user to enter within the confines of a certain filtered part of the data. The numbers can be reused eventually, just in different subsets of the database. To be clear, the number needs to be unique within entries of each term and year pair only, and the entry of those numbers will be within a filtered group, unrelated to any others. My thought is to let the serial number get up to 999 and then revert to 1.
The standard form appears to be: create preferences table + auto entered serial number field. Script creates new record (locking record by Corn's suggestion in another post using Open Record[ ] and checking for any errors - thank you Corn) and collecting the serial number to a variable > continue.
Then, I wondered why do I need a whole table and 999 records? In inventory solutions and transactional solutions, numbers sit in fields and you pick them up, add one and set the field with the addition. Maybe that would be fine? Why not?
Or, would there be any advantage to having my one record utility table have an auto enter serial number field that actually never does anything, but holds the next serial number for me to collect and then I set next serial number to the collected number plus one?
What I don't like is having to go to a layout to collect it, but the global field needs attention everytime I pull it down for development and put it back up. Maybe my one record utility table record can be accessed like a global because the first record is the only record, and that could show up in all relationships to it.
Any thoughts on the best way or why one way is the wrong way?