Ask yourself what does FileMaker do when you move to another layout? At a minimum it commits the records and displays the visible fields. It processes triggers, hides objects, and conditionally formats too..Is their a commit records step in your delete script? Does your delete script have a refresh window flush cache joins step or some other method to cause refreshing of the join data? You need to programmatically replicate what FM would do without actually changing layout context.
Thanks for the response.
The layout is based on file A. It has no modifiable fields. My understanding of a portal is that if a relationship exists, then the portal will display the related records automatically. This is true when moving from one record to another in the header portal. The child records display correctly in the portal without a commit on file A, The global is set to the key and the records display automatically. My problem is understanding why it is necessary in the case of deletions to commit the record from file A to have the relationship link between the Layout file A and the child file C display correctly in the portal.
Anyway I have replaced the 'goto layout' with a commit which solves the issue but I must say that i find it rather odd.
The actions that cause commit:
Commit record script step.
any script or user action that changes record, layout, or mode.
any script or user action that closes window.
click to exit field without entering another field.
Delete portal row via without commit and FileMaker may not have refreshed the hidden cached join data. Commit causes refresh.
The cached data remaining unaffected by the portal delete until the base layout is committed explains the situation.
Thanks for the help.