Try clicking a blank area of the layout to commit the new portal record. Then see if things update and function as expected.
Commit records can be scripted so that your GTRR button that takes you to the portal record then commits records.
It did occur to me that it could be a commit records problem, so I put a Get ( Record Open State ) calculation on the layout. It confirms that the record is committed ( 0 ) when it is created. I also put a Commit Record button on the layout to test it manually, and got the same result.
It also may be important to note that once the child record is created in the parent portal, the child record's serial ID (not used to relate the tables) does not display in the portal where it should, but the GTRR function does work, and does still go to the correct new child record. Also, once on the child layout, a modify or commit in any other field will not establish the relationship, only a modify in the parent ID match.
once the child record is created in the parent portal, the child record's serial ID (not used to relate the tables) does not display in the portal,
And is the serial number set to be generated On Commit or On Create? There's a setting in Field options that controls this.
But something is not right here. I was surprised from the beginning that GTRR would work. I just set up a simple test to confirm this and GTRR will not bring up the related record for a record that I've created in the portal unless I first commit records. I did this simply by clicking the layout background and then clicking the GTRR button to pull up the new record.
And then the new record is shown on the portal table's layout and fields from the parent table correctly display the expected data.
Is it possible that the GTRR is pulling up a different record from the one that you just created in the portal? Such as the very first record in the portal?
The serial was set to generate on commit, and changing it to On Create made it appear right away in the parent portal after the name is saved. New child records still behave the same way, though.
The portal GTRR takes me to the correct record each time, even if there are multiple child records that do not recognize the relationship from the child context.
Also, once on the child layout, a modify or commit in any other field will not establish the relationship, only a modify in the parent ID match.
A correction to that statement though; modifying any field on an "unrelated" child record WILL establish the GTRR functionality, but the merge fields remain blank. Leaving the layout and returning, or entering and exiting Edit Layout mode then fills the merge fields, whereas the merge fields are filled instantly when the parent ID is modified.
I've recreated the system in a new database and I don't have any of these problems, nor does the parent-grandparent relationship in the same database. As far as I can tell, all of the serial numbers and relationships appear to be defined in the same way. The biggest difference I can see is that the child table has been in use for 15 years and has over 3000 records, whereas the parent and grandparent tables are new additions.
If a new file does not show the same issues and you are confident that you have not overlooked any details, the file itself might be damaged. Recover the file, and even if the recover process does not report finding any problems, test the recovered copy and see if it works for you. (Recover also rebuilds all field indexes so the index rebuild might alter behavior even though no problem was detected during the recover.)
But I am still puzzled as to how the GTRR button can possibly work until you first commit the new record back to the database...
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).
I wish I could say I had found a reason for this, but it seems to have solved itself. I came back after the weekend and the exact same relationships that didn't work before worked exactly like they should have. Maybe restarting the hardware fixed it?
Either way, thanks for the help.