6 Replies Latest reply on Aug 8, 2009 5:52 PM by RickWhitelaw

    One more Go To Related Record Inconsistency

    philmodjunk

      Summary

      One more Go To Related Record Inconsistency

      Description of the issue

      Depending on your point of view, this is either a bug or undocumented behavior: Two tables: Invoices and LineItems with LineItems related via a serial ID number in Invoices, allow creation of LineItems via the relation is enabled and LineItem records are displayed in a portal on an Invoices layout. Create the following script:If [ Count ( LineItems::InvoiceID ) > 0 ]  Go to Related Record [ From table: “LineItems”; Using layout: “LineItems” (LineItems) ] [ Show only related records ]  Show Custom Dialog [ Title: "Exit Line Items"; Buttons: “OK” ]End If Set an "on Exit" script trigger on the LineItems portal.Enter data in the portal to create at least one related LineItem Record.If you exit the portal row, the script correctly takes you to the LineItems layout shows the related record and pops up the Custom Dialog. Now click in the bottom blank row where you would add a new row of data. Without entering any data, click on the layout background to trigger the On Exit script. This time, GTRR does nothing, and the Custom Dialog pops up to confirm that the script did execute. Note that there WAS a related record in the portal when I triggered the script just not on the active portal row. If you read the documentation on GTRR carefully, you'll find that "If this script step is used from an active portal row, and the portal’s table is the related table, then the related record in that table is made current." Apparently, the combination of an active portal row but with no related record in the active portal row keeps GTRR from functioning in a manner similar to GTRR failing when there are no related records. As a work around to avoid this issue, Use IsEmpty (LineItems::InvoiceID) as a test to keep the script from executing. Please note that both GTRR silent failures are undocumented in the help file and can be extremely hazardous to your data as they could leave an entirely different table as the current table while looping through records and changing them, performing a replace field contents, deleting records... System Info: Windows xp, FMP 10 adv v3

        • 1. Re: One more Go To Related Record Inconsistency
          comment_1
            

          I believe it behaves as expected. When you are in a portal row, "related record" means the child record in the current row. If the current row is empty, there is no related record to go to.

           

          The script triggering part is only misleading here; it would behave the same way if there was a button in the portal.


          • 2. Re: One more Go To Related Record Inconsistency
            philmodjunk
              

            I agree in part. Yes, the script trigger part is irrelevant. A triggered script was simply how I stubbed my toe on this one in the first place.

             

            "When you are in a portal row, "related record" means the child record in the current row. If the current row is empty, there is no related record to go to."

            GTRR is documented as going to all related records and there are other related records present in the portal, just no specific record in the current portal row to select as the current record after the related records are selected on the designated layout. As I stated in the first post, this keeps GTRR from doing anything and it silently fails.

              

            My main complaint here is the sad lack of complete documentation in the help file on what circumstances will cause GTRR to fail nor are there any warnings about potential consequences of this "silent failure". Thus, GTRR in the hands of an uninformed developer can have disasterous consequences for the records in their database.

            • 3. Re: One more Go To Related Record Inconsistency
              comment_1
                

              PhilModJunk wrote:

              GTRR is documented as going to all related records


              I don't think so:

              "Goes to the current related record(s) in a related table, except when this script step is used from an active portal row.

              ...

              If the currently active portal row is row #3 and you execute a Go to Related Record script step using the same relationship as the portal, then FileMaker Pro goes to that particular related record in the related table."

               

               

               


              PhilModJunk wrote:
              GTRR in the hands of an uninformed developer can have disasterous consequences

              As can any other feature.



              • 4. Re: One more Go To Related Record Inconsistency
                philmodjunk
                  

                I'm familiar with this section of help file. I reviewed it before I ever started this thread.

                 

                Take another look at what you quoted in red. It makes my case.

                 

                The help file tells the user what will happen when there is a a record in the current row of your portal. It pulls up all related records (not just the current portal row record) and makes the current portal row record the current record in the newly created found set. It does not tell you what will happen when there is no record in the current portal row. Instead, the developer is left to discover what happens through actually attempting to use GTRR in this circumstance with potentially disastrous results.

                 

                I said "GTRR in the hands of an uninformed developer can have disastrous consequences"

                and Comment replied:  "As can any other feature."

                 

                Yet some are far more disastrous than others and this one's right up there with the Import Records issues. Since GTRR's failures are "silent" (script execution is not interrupted and no warning dialog appears to tell you it didn't work) and can leave an entirely different layout with a different underlying table as the current layout, it can result in massive numbers of records being changed or deleted in completely unexpected ways--with no warning to the user that this happened. Furthermore, since the help file doesn't document this behavior, it's not easy to become an "informed developer" in this case. Other forum participants have even stated that "they don't use GTRR because they keep having problems getting the results they expect"--this is no surprise given the woefully incomplete documentation and "silent failure" behavior of this script step.

                • 5. Re: One more Go To Related Record Inconsistency
                  TSGal

                  PhilModJunk and comment:

                   

                  Thank you both for your comments.

                   

                  I have forwarded this entire thread to the persons responsible for our documentation and Help files.

                   

                  TSGal

                  FileMaker, Inc. 

                  • 6. Re: One more Go To Related Record Inconsistency
                    RickWhitelaw
                      

                    I just scoured my business solution for instances of the GTRR step. I found a few, but all were "display" oriented and often were setups to printing. I'm an amateur (I don't write for others), but never felt the GTRR step necessarily provided the "absolute lock" needed to perform actions of any consequence directly on data. By pointing out some of the pitfalls and limitations of GTRR, you've also shed light on some of the possibilities of the step. You're caveats seem well-founded. With the proper error capturing GTRR can save a few lines of script. However, like many routines, it's more of a short-cut than a concept with any particular value of its own, with one exception, perhaps a different type of time-saver: it can display the related record in the layout chosen, which I suppose could be useful . . . seems odd 'tho.

                     

                    Rick.