10 Replies Latest reply on Jul 6, 2017 8:56 AM by CICT

    Beware GTRR Error Trapping


      In case this helps someone avoid the time I've taken to understand this, I usually use 'If Get ( LastError ) = 0' after finds and go to related records.


      Today we're creating a new report for one of our insurance system that requires a find on policies within a date range and then we have to go to the member linked records and after that the mid term adjustments (MTAs) hence GTRR matching found set is perfect as we've thousands of records on our initial find and we need to go to the 'line item' member/MTA records after that.


      However, I was getting '[101] Record is missing' error, despite a subset of records displaying successfully.


      I believe I've traced this to the record selected in the parent table at the time GTRR matching found set is run. If that record has a linked child table record, then no error is reported. However, if the record you're in at the time doesn't have a linked record then the [101] error is reported. The same record set is displayed each time, it is only the error reported that changes.


      This effectively renders Get ( LastError ) = 0 useless and we're going to have to use another method, maybe using the layout name or more likely check for error 401 if there genuinely are no children records to navigate to.





        • 1. Re: Beware GTRR Error Trapping

          This is a similar type scenario to people wondering why they get a 101 error at the end of a loop in filemaker:


              //Do loop stuff

              Go To Record [ Next ; Exit After Last ]

          End Loop

          The above will always return an error, literally because there is no next record to go to when you hit the end of the loop.


          So proper error-free looping looks like:


             //Do loop stuff

              Exit Loop If [ Get(RecordNumber) = Get(FoundCount) ]

              Go To Record [ Next ]

          End Loop

          FileMaker is very literal in some cases of it's error engine, but very forgiving in others. This is why it's important to always run some tests of your scripts with the script debugger and "pause on error" checkmarked, so you can identify errors and properly code around them or detect them.


          Thanks for sharing!

          1 of 1 people found this helpful
          • 2. Re: Beware GTRR Error Trapping

            Hi Mike


            Yes I do wish FileMaker Server wouldn't report these types of errors in their log, or allow us to suppress them as an option when looking through scheduled scripts for instance or shooting of email warnings.


            It is never straight forward. For instance in the example you've given, we've been caught out in the past if the penultimate record is to be omitted within the do loop stuff, then the last record doesn't get processed.


            We're always having to look at things from so many angles, but I guess it is what makes it fun


            Thanks for the contribution.



            • 3. Re: Beware GTRR Error Trapping

              Am I correct that you are using the "match found set" option with GTRR?


              I believe that you'll get that error if any record on the found set has no matching records, but could easily be wrong.


              I test for failure in this situation as follows:

              Set variable [ $Layout ; get ( LayoutName ) ]

              GTRR (with "match found set")

              iif [$Layout = get (LayoutName) ]

                   GTRR failed

              1 of 1 people found this helpful
              • 4. Re: Beware GTRR Error Trapping

                Yes Phil


                We produce a list of a few thousand parent records and then need to list all linked records to these.


                The error 101 is the error if you just match the current record and there are no linked records.


                However, this also appears if you match all records if the record you happen to be in at the time doesn't have a matching child record, even though others do. So you can get a successful navigation, but an error relating to another setting in the GTRR configuration - you don't get a 101 error if you happen to be in a record that does have a linked child record.


                Error 401 is the one to trap for, as this will happen if there are no linked records to any of the parent set. As you say, you can trap for the layout not changing, but we've opted to trap for error 401.


                Kind regards


                • 5. Re: Beware GTRR Error Trapping

                  If [ NOT IsEmtpy (child::parentKeyID) ]

                       GTRR [ child::ParentID; ...]

                       ... other optional steps ...


                       ... do this instead, if desired ...

                  End If

                  Test the relationship for child record(s) and only GTRR if there any. No more error.


                  1 of 1 people found this helpful
                  • 6. Re: Beware GTRR Error Trapping

                    Hi Beverley


                    This would only work for a match current record. We're starting with say 6500 records and usually getting between 13,000 and 25,000 child records for one scenario (policy members) and just a few for another (policy mid term adjustments). But if the record we happen to be in at the time is one that doesn't have a child ID, then we'll get a 101 error despite the successful navigation to the 13,000 plus records in the new layout.


                    The issue is that we can't use Get ( LastError ) = 0 despite a successful navigation as FileMaker is reporting on for a situation we haven't selected. Ideally, when selecting 'match all records' there should be a flag in the background that suppresses the 101 error and the script step should only report 0 for a successful navigation or 401 for unsuccessful for the task that has actually been selected.


                    I know this has been raised in other forums in years gone by, but it took me a while to discover why my script wasn't running after the error trapping, so hope this will help someone else save time in the future.


                    Kind regards and hope all is well



                    1 of 1 people found this helpful
                    • 7. Re: Beware GTRR Error Trapping

                      Thanks for the clarification, Andy! You can still omit that record (with no related children) and try again the GTRR.


                      But I understand it would be nice to be able to capture this error as is and not have it show just because you happen to be on a parent with no children.



                      • 8. Re: Beware GTRR Error Trapping

                        Thanks Beverley


                        Yes, we could agreed, but we'd also have to loop through the complete found set and now we've identified the, in our opinion, erroneous error message, we're on top of this.


                        Kindest regards



                        • 9. Re: Beware GTRR Error Trapping

                          Loop? how about CONSTRAIN to just the found set with child values?


                          1 of 1 people found this helpful
                          • 10. Re: Beware GTRR Error Trapping

                            Good point.


                            However, we'd need to do this in a new window. We use the main list for 2 separate GTRR, first the policy members, then the policy MTAs, and it is starting to get a bit over the top as all we want to do is to use a single GTRR script step.


                            Once the nuances of this option within GTRR are known, then it isn't such a problem. However, I still don't like error messages when in pure logical terms, there isn't one.


                            Hey ho, use the tools, make the compromises - LOL!