Thank you for your post!
" "IndivID" is defined to contain unique values only. You must enter a unique value."
That means that your new record did not have a unique ID. You might be setting this Unique ID field (IndivID) as an Auto-Enter Serial Number. If that is the case you can go to Manage > Databases > Field Options for IndivID and set the Next Serial Number Value. Setting this properly may resolve your issues and provide Unique Values again.
I'm also going to move this thread from the FileMaker Community Feedback Space to the Discussions Space where others might find your post easier and offer further advice.
Thanks for your reply and for posting the question in the correct place.
The Next Serial Number Value is set to be 11851, and that should be correct as there is not yet a Record with that number.
After deselecting "Unique Value", I and several others tried, as an experiment, to create New Records simultaneously on several computers to see if we could create any New Records with the same "IndivID" number. We were unsuccessful.
However, someone created a New Record on Friday, and somehow, mysteriously, managed to create another New Record with the same IndivID number.
If you can afford it - and by that I mean not needing to revolutionise your whole design and not needing a progressive number (which you can get by other means anyway) - get rid of all this complication and use Get(UUID)s instead of serial numbers. You don't really need a record serial number, you only need a unique label.
You could always reinstate the validation and figure out why their is a conflict in the data. Its probably that the next value is not set correctly. Be careful... if you have duplicate IDs and have cascading deletes turned on its gong to cause some problems.
If the ID field is not set to ALWAYS validate, then it is possible that someone imported those records that are dupes, or someone imported the records immediately before the second dupes but did not select the option for FileMaker to automatically apply auto-enters, lookups, etc....which means that the "next serial number" did not get advanced on the import.
The ID field was not set to ALWAYS validate (but to validate upon data entry). So I changed it. We are testing it to see if that fixes the problem.
The odd thing is that we never IMPORT data into our database. However, we do scan it in, using barcoded ID's, when people enter our center and get other services.
Also, these second Records created with duplicate ID numbers are not always being created, and when they are created, all the fields are blank except for the ID number (IndivID) field.
Thanks for any additional speculation about what might be going on.
Not even when moving to a new and updated version of your solution?
That's, by far, the most common source of such duplication. The new file doesn't get it's "next serial value" setting updated correctly and when data from the previous copy is imported, you get a situation where new records will duplicate those of existing records. The fact that you've checked and the "next value" setting doesn't seem to be wrong may simply mean that you've created enough records that this issue won't recur.
Frankly, auto-entered serial numbers--with the exception of cases where some records are imported for one reason or another, has been darn near "bullet proof" in my experience. You simply can't get duplicate serial numbers unless some other agency is either importing records or modifying the serial number after the record is created.
As everything we do is located at one site, we don't have any data we would import. So we never import data in the sense I understand the term.
We recently updated the Mac OS system, and were told by Filemaker Pro people to reinstall the FM Pro Server software, which we did. But I did not touch the actual FM Pro files on the Server Computer. Could the files themselves need to be Compacted/Recovered?
Examining all our existing records, the highest IndivID number is 11866, and the next record to be created is set up to get 11867.
Thanks for any additional ideas.
Sometimes you need to maintain auto enter serial number because of laws. In France, fiscal services wants to have chronological numbering of pieces that lead to accounting and they must be able to see if all pieces are present. If I numbered bills with only UUID, I can't see the chronogical order, If I use auto enter serial number, I will immediatly see if a bill is missing.
You can use UUID, if you manage yourself a counter in someplace of the database, like à parameters table.
And also, what happens if sort is made with UUID instead of a serial counter ?
1 of 1 people found this helpful
It's possible to have the UUID acting as the unique ID for the record AND to have a serial number too.
What happens if sort is made with UUID? It will sort, and we should expect the sort order to be fairly random, with respect to creation order. However, you'd expect the natural sequence of the records to be chronological, ie, unsorted records are displayed in chronological order ( the sequence of creation ).