FileMaker Pro looses focus on an open Layout when Related Record not found
Operating system version
Mac OSX Yosemity
Description of the issue
I have a Table, call it Table1 that is shown on a Layout, call it Layout1. There is related occurrence of this table, call it RelatedTable1. My script first goes to Layout1, finds the first record from Table1 in Layout1, and then Goes To Related Record from the RelatedTable1, snatches some data from a field or two in the related table, and then does a little work on the data and stores in in a field in Table1, all without leaving Layout1, then commits the records, and moves on to Next record in Table1 etc.
The above script works perfectly. UNTIL a record in Table1, happens to NOT have a related record in RelatedTable1. When this happens, I do some error handling for it, and the scripts attempts to save the aforementioned fields from Table1 with default values. However, these attempted Set Field statements cause internal errors (101 or 401 as I recall), apparently associated with the fact that there was no matching related record for the Table1 record that was selected in Layout1.
This is not an issue per se in my current script because those same values I attempt to set, are defaulted at record creation to values which work for me. However, I could easily envision a slightly different version of my script where this would not be the case, in which this deviant behavior of FMP would have caused me great debugging pain and then grief to fix.
The point is this. Irregardless of ANYTHING (and I do mean ANYTHING!), if FMP is sitting on a Layout1, that has as its associated table, Table1, then WITHOUT EXCEPTION, the record and its subordinate fields that are showing in that Layout1 should be accessible, readable, and writable from my script: end of story, don't pass Go, and do not collect $200! (the game of Monopoly in case you are not old enough ;-)
This does not appear to be the case if there is a Go to Related Record step and there ends up not being a related record. Just because there is not a related record, does not mean that ANYTHING about the context of Layout1 or Table1 should change. It violates all the supposed consistency rules in FMP to do otherwise.
Steps to reproduce the problem
Go to Layout [ “Layout1” (Table1) ]
Show All Records
Sort Records [ Keep records in sorted order; Specified Sort Order: [ Restore; No dialog ]
Go to Record/Request/Page[ First ]
#Set the match field to look for in RelatedTable1
Set Field [ Table1::g_Match; 4 ]
Commit Records/Requests [ Skip data entry validation; No dialog ]
Go to Related Record [ From table: “RelatedTable1”; Using layout: “RelatedLayout1” (RelatedTable1) ] [ Show only related records ]
SOME ERROR HANDLING HERE
Constrain Found Set [Restore]
#in the above, I do a find that is indicative of a specific related record I'm looking for
#Then at least one RECORD has been found, so grab it (I'm only interested in the first one found)
Set Field [ Table1::DataField1; 1 ]
#A RELATED RECORD was NOT found for this RECORD
#THE NEXT STEP WILL CREATE AN INTERNAL ERROR
#FORTUNATELY IT DOES NOT STOP THE SCRIPT, BUT THIS MISBEHAVIOR WOULD CAUSE ME MUCH DEBUGGING TO FIND
#SINCE I HAVE NOT LEFT THE Layout1 LAYOUT, Table1 SHOULD STILL BE ACCESSIBLE TO ME!
#IT IS, IF A RELATED RECORD WAS FOUND
#ITS IS NOT, IF A RELATED RECORD WAS NOT FOUND
#IT SHOULD NOT MATTER WHETHER THE RELATED RECORD WAS FOUND OR NOT
#FMP IS STILL POINTING TO Layout1, SO I SHOULD STILL HAVE FULL ACCESS TO Table1
#THIS INCONSISTENCY NEEDS TO BE FIXED.
Set Field [ Table1::DataField1; 0 ]
Go to Layout [ “Layout1” (Table1) ]
Go to Record/Request/Page [Next] [Exit After Last]
The expected results are described in the above.
Basically, since I never changed the layout, I should still be able to have full access to the record that was showing in Table1 when I started.
However, FMP acts inconsistently, allowing me access to the record and fields in Table1 when a related record is found, but NOT allowing me access to the record and its fields from Table 1 when a related record is NOT found. It simply should not matter whether what goes on in-between if FMP is still pointing to the same table I started with.
Exact text of any error message(s) that appear
I can't recall if the last Set Field step produced either a 101 0r 401 (one of them that indicated that FMP could not "see" the field that was being assigned from Table1.
Yes I can work around it. But the point is that I should not have to discover the hard and hidden way that this misbehavior is going on. It should be consistent and right now it is not. And, it should be made to aid the FMP programmer not hinder him/her. The later means that all Table data should be made available to the programmer when ever possible to avoid needless Layout thrashing and also needless use of global variables to pass data between Tables.