This is known behavior for Go To Related Records. I tried to report this one myself and was told that is is not a bug--even though GTRR will update the found set with no related records if You can use the current layout designation for your GTRR (self joins only).
GTRR also does not change layouts if there are no related records which can really produce disaster if you do not check for related records.
There is some documentation of this in FileMaker help:There are situations in which a script containing the Go to Related Record script step could modify an unintended set of records. For example:•If the related records cannot be found, this script step remains on the current layout.•If you select a table occurrence to which there’s no relationship, or a layout that doesn’t refer to the correct table occurrence, FileMaker Pro displays an error message. After the error message displays, script execution continues with the next script step.•If there are no related records or no record in the active portal row, the script might produce unexpected results. Use the IsEmpty function to determine if there are no related records before using Go to Related Record.•If you have Allow creation of related records enabled and Go to Related Record is executed from an empty portal row, the script might produce unintended results.
For a more complete look at all the ins and outs of GTRR: The Complete Go To Related Record
thank you, very interesting.
anyhow pls. have a look at http://help.filemaker.com/app/answers/detail/a_id/493/kw/Scripting%20Error%20101 in which I understood that the normal behavior is to change the layout.
Moreover, the problem is that you get the same error code (101) both if there is 0 related records (layout not change) or if not all records in the current found set are matched (layout switch to the selected one).
So, in reality you cannot test the error code (101) because you can be in the starting layout (0 matches) or in the specified layout of the related table.
I do not think this is a congruent behavior: I’m expecting to be anyhow in the layout of the related table, with the found set from 0 up to all matches.
In this case you can know:
Test the error = 101: not all the original found set are matched
Test the error = 0: all the original found set is matched
Test the number of records in the current found set: if = 0 you know that there are not related records.
I found and referred to the same article when I posted my bug report here. Note that it only refers to FileMaker 7, not current versions. As far as I can tell, somewhere along the line, the powers that be decided to leave the issue as is and not consider it a bug. (In pre 7 days, you didn't specify a layout, had fewer options, but zero related records produced an empty found set.) Please note that I've long thought that zero related records should produce an empty found set, but FileMaker Inc. disagrees...
Error Code 101 stands for "record is missing". that makes sense in what you describe since it's true for at least one record in your found set in your example, it's just not helpful as a way to test for a successfull GTRR execution.
Frankly, "Match all records in current found" set is an option to be used carefully and avoided when possible. It can put a major performance hit on your system in some cases.
There are other tests besides trapping for error codes that you can use.
If you use the more commonly used "match current record only" option you can check for the presence of related records just before the GTRR step:
If [RelatedTable::ForeignKey //assuming ForeignKey is a field of type number]
If [ Not IsEmtpy ( RelatedTable::foreignKey ) //works even with text data type]
But you can't use that with the "Match found set" option as this can be false for the current record, but true for others in the found set.
What you can do is compare layout names before and after the GTRR to see if they change:
Set variable [$LayoutName ; value: Get (LayoutName) ]
Go To related Records [...
IF [Get ( LayoutName ) ≠ $layoutName ]
Note that this test will work even if the layout gets renamed at some later point.