I know it's not likely, but any portal or relationship filtering, or triggering that would explain the disappearance? Is there validation on the "Document No" field that might cause a hassle?
It looks like the OnRecordCommit trigger is not firing when you tab between the fields. Not sure if this is expected behavior for external file referenced tables inside of portals, but in my experience I can't recall ever seeing this behavior.
All good ideas, but no. That's what has me flummoxed. There are no triggers or validations anywhere. I even deleted the portal object and copied it from the one that's working (changing the pointers to the correct table), and that didn't seem to make a difference.
As the Aflack duck might say, "Huh?"
Have you tried doing this with the script debugger open, just in case?
This doesn’t seem like corruption at all.
Also, was this recently switched between versions of FM? with the addition of the refresh object script step, I would anticipate that some prior refresh actions are different now.
Alas, the debugger indicates no scripts are firing at any point in the process.
The solution was upgraded to version 12 about ... 7 - 8 months ago. A much more recent change was the separation of the database about 3 weeks ago. (Up until that time, it was a single file solution.) I separated out these two tables because they're external container tables and I was sick of dealing with the migration issues.
The process for the separation was (more or less):
1) Duplicate solution
2) Delete stuff you don't need from new external container file
3) Repoint TOs for external container tables in parent file to external container file
4) Delete container tables from parent file
Something in there, maybe?
It's curious to me that you would duplicate the entire file to remove what you don't need, rather than just exporting the two tables you did need and building the external file from there.
I don't see anything wrong with that process though.
It doesn't seem like a permission / authorization issue either.
Sorry, not thinking of anything wrong. A simple way around it though would be an OnObjectExit script trigger on the fields in the portal that forces a commit/refresh.
I'm almost to that point. But I thought there must be something structurally wrong for it to act this way; this is FileMaker 101 stuff here.
And the duplication was to preserve some auto-enter, external storage path and calculation options. Six of one, half dozen the other, but I trust myself more to delete stuff I don't need rather than remember to fix all the stuff I do.
How is the relationship defined? What fields are required to create the record?
I have found similar problems with auto-create relationships where I set one field by script, then set a second field.
Setting the first field should populate the global on the "left" side of my relationship.
And this has worked in the past.
However, I find that in FM13 I must first set field; then commit; then set the second field (plus any other fields); then clear the left side selector to deselect the record.
What happens in your case if you set one field, commit, then re-enter that portal record and make any other edits?
The relationship is defined based on an auto-enter calc (parent side) and a plain text field (child side). There are no required fields per se, although the child table does have a primary key (also an auto-enter calc). The parent record is already in existence prior to attempting to create the child record.
That said, the process you describe - set one field, commit, then re-enter - is our workaround at the moment. Oddly enough, we're still on version 12 here, though, so I'm not sure it's due to a version change. I don't remember having the problem before splitting the solution into two files, but the one table is still working normally. Only this table is acting up, and it's nearly identical to the one that's behaving (minus some global fields not related to the operation).
This one has me really scratching my head. Thanks for looking at it.