But which field is triggering the error? might it be Pregnancy::ContactID?
Pregnancy::PregnancyID seems to be the problem. It is supposed to auto-create when a record in the table is created, but it doesn't appear to be doing that anymore. It is not on the layout, but it's been this way the whole time. Why is this just now showing up, and why can't I recreate it? I'm wondering if my set-up in the auto-create of the serial number to begin at a certain number is now causing a conflict??
Just to rule out possible issues, I'd run a recover on the file.
I'd also check field options on any field in any table of any file that is named PregnancyID to make sure I haven't missed any details when it comes to validation and auto-enter settings.
I recovered the file and it gave me the following:
"Recovery built a new database without detecting any problems. The new database is safe to use, though you should monitor the results carefully and make sure to keep up-to-date backups of your databases.
File Blocks: scanned and rebuilt 1290 blocks, dropped 0 invalid data blocks.
Schema: scanned fields and tables, 0 items modified
Structure: scanned; 0 items modified.
Field indexes: rebuilt."
Problem is still occurring, but only on the version given to my beta testers. It doesn't happen in mine. I'm wondering if it has to do with starting the autnumbering on something other than 1?
Thank you for your post.
Since this only happens with one user, it is possible that FileMaker Go may be damaged. Connect that iOS device to iTunes, copy off all the local database files, and then remove FileMaker Go from the device. In iTunes, download a fresh copy of FileMaker Go to the iOS device, and then copy over the local files to FileMaker Go again. Once reinstalled, try again. If this fails, continue to find out what is the difference between the iOS devices that do work and this one iOS device.
I opened the file with the error on my Macbook in FMP and it causes the same error. Christmas planning is intruding on this project, I'm going to have to sit down with them side-by-side and figure out the problem. Thank you, I'll keep digging, if I find something and need more help, I'll bump this.
since a few weeks we suddenly have the same problem with 2 clients. Both of them never used FMGo. It is 1 SetField ScriptStep that creates a record in a subtable via a relationship. The subtable has field (named ID) that is set to generate a serial number on record creation.
This scriptstep does not produce any error at other clients. It doesn´t matter, if we put the ID field in the Layout (according to the error message), instead it seams to be a timing problem (the Computer is fast enough, it´ts the latest MacBook Pro):
1. ScriptStep SetField subtable::textfield is being executed (to create a related record in subtable vie relationship)
2. The error message appears
3. The serial number Field subtable::ID gets its serial number
Error Capture captures no error
The only solution we found:
SetField subtable::ID directly (with a selfcomposed ID - and avoid the generate serial number mechanism) instead of subtable::textfield to create the record in the subtable
(FMP12v3 Mac and FMP 12v4 Advanced Mac - never had this error on FM10 and FM11)
Thank you for your post.
You mention that the subtable has a serial number generated on creation. I assume this is the record primary key. Make sure you are matching up the foreign key field with the primary key of the current table.
Perhaps you could provide more information how the relationship is set up, plus what fields have Auto-Enter data.
the field subtable::ID has been originally created to be the primary key. But so far we didn´t use the field (we found it a good idea to have field that has a unique ID if we need it later). Currently it is only an unused number field with a serial number.
The relationship Addresses (the maintable) / subtable is as follows:
Addresses::ID - subtable::_fk_ID_Addresses
To create a record in subtable form a Layout based on "Addresses" we use another field subtable::constant an filled the value 1 in the script step.
(We also testet to fill some text in a Textfield subtable::text_1 - it doesn´t matter which field is filled, we ALWAYS get the same error - only Setting something directly in subtable::ID prevents the message from appearing)
• The Message appears shortly before the field gets its serial number (we put subtable::ID in the layout. The serial number is there, right after clicking away the error message)
• This happens only to 2 clients.
• It´s computer independent: They gave us their database files an we can confirm the error on our computers too
• Recovering of the file gets us to the same point as Anita Woods: "Recovery built a new database without detecting any problems..."
• Changing the SetField ScriptStep from subtable::"any field" to subtable::ID prevents the error message from appearing.
Thanks for the additional information.
If you are able to reproduce the problem, then I'd like to see the file. Check your Inbox at the top of this page for instructions where to send the file.
sorry, it is strictly forbidden to send our clients files to you. They contain confidential information
Since you cannot send in the file, are you entering the information directly into the portal? That is, do you have "Allow creation of records in this table via this relationship" for the subtable? Or, are you capturing the ID into a variable, adding a record to the subtable and setting the foreigh key field to the value of the variable?
Do you have any other relationships connected to the subtable?
Any other information you can provide to help me reproduce the issue would be appreciated.
I just had this exact same issue.
I maintain a database for a client, where I recently split the database into a Layout file and a Data file, enabling easier updates to layouts, scripts and relationships without touching the already entered data.
During this process, I received a copy of the original "combined" database with new data that the client had worked on. This data was imported into my new split version.
This is where it must have gone wrong, as the client afterwards had trouble creating some records in a portal.
It gave the exact same error as you mention and the cause was that the ID field in the related record, which was created upon data entry in the portal, inserted a new autogenerated serial, but this number was an old (lower) number, than the newer ID's that were imported.
Thereby the same ID existed twice, which the validation scheme caught and threw that error.
...is to verify and set the autogenerated "Next serial value" on the ID field (on the table in the portal) as a number higher than the existing records highest ID, to ensure it is unique upon creation/commit.
The problem is that the error thrown does not specify that it is a validation error related to multiple identical ID's, which causes confusion as to what the error actually is.
The error description just seems like the ID field does not contain a value, even when it was autogenerated.
The field validation was set to "Unique", but not "Not Empty", but still got the same error as you did.