3 Replies Latest reply on Jan 25, 2012 2:50 PM by philmodjunk

    The Go To Related Record Script Step Does Not Update The Related Table's Found Set If There Are No...

    GianandreaGattinoni

      Summary

      The Go To Related Record Script Step Does Not Update The Related Table's Found Set If There Are No Related Records In The Found Set

      Product

      FileMaker Pro

      Version

      FM 11.03, FMA 11.03

      Operating system version

      wondows 7, windows vista

      Description of the issue

      The Go to Related Record script step does not update the related table's found set if there are no related records in the found set.
      The related table's found set is expected to change to show zero records.

      This issue should have been corrected in version 11.02, but it's not (Answer ID: 493, Oct 31, 2007)

      Steps to reproduce the problem

      set a script with Go to Related Record instruction when there are no related record.
      The layout do not change to the destination layout specified in the Go to Related Record instruction, displaying 0 records, but remains in the actual layout with error = 101.

      Expected result

      The related table's found set is expected to change to show zero records

      Actual result

      the found set is not changed

      Exact text of any error message(s) that appear

      error 101

      Workaround

      trap the error

        • 1. Re: The Go To Related Record Script Step Does Not Update The Related Table's Found Set If There Are No...
          philmodjunk

          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

          • 2. Re: The Go To Related Record Script Step Does Not Update The Related Table's Found Set If There Are No...
            GianandreaGattinoni

            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.

            • 3. Re: The Go To Related Record Script Step Does Not Update The Related Table's Found Set If There Are No...
              philmodjunk

              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]

              or

              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.