Without knowing the specifics of the relationship structure and security, I can suggest checking a few things.
- All relationship keys have to be indexed or they won't work, so using a calculated key might be problematic depending on how and when the calculated value is stored.
- If you are entering a portal or related field via a parent record which has not yet been committed, the relationship will not be valid until after the parent record is committed. Working in a list view, as you show, it is not clear which record you are working in.
- If the permissions you are using at the time of data-entry are not Full Access permissions, you might check the settings in security for creating and editing records in this "source" list. Often developers restrict such tables for editing, and then get bit by the restrictions when logged in as a regular user.
- I have even seen this type of error where there was only one global record as the parent record, with a K join-key to all other records in the child table, but the editing failed with a similar message if the global record found set was 0 records instead of the existing (or missing) global record. Be sure the parent record is in the found set, even if it is the only record in the parent table.
Would you mind checking out my sample file I just attached to my original post?
Okay, now I see what's wrong!
You are creating records via a portal, which means that FM is trying to write the parent record's Key field value into the child key field. It can't do it because you have defined the child's foreign key field to be a calculation, which FM cannot alter, so it's essentially telling you that it cannot write the proper key for the portal-creation process.
When I changed the child record's field definition for that key field to indexed text in your sample file, the portal creation process works fine. You gotta let FM write the value for portal creation to work.
I don't quite follow you...which table and what field do I change the indexing on?
In the portal's child table (Zip Codes), change the Key field from a calculation to Indexed Text, and all will work.
FM cannot process the writing of the key into the child record as required by the portal-creaion process if the field is not modifieable (i.e. a calculation). So it fails to create the related record, having been defeated in its effort ot write to the key field.
Oh OK...that makes sense! Thanks so much for your help!