13 Replies Latest reply on Jul 16, 2012 8:28 AM by BryanN

    Navigation to related records

    BryanN

      Title

      Navigation to related records

      Post

      To be short, I have Customers, Vendors, Jobs, Purchase Orders and Quotes all setup as separate tables with correct child tables, heirarchy, etc etc...

      My question has to do with navigation scripts.  I have a menu of buttons that navigate to the specific areas.  However, I like to use (when possible) the "go to related record" action as it has a great context for the user to always see data related to what he's been looking at.

      However..

      There are examples such as this that break these buttons: my user goes to Purchase Orders to create a Purchase Order record, realizes he needs to create a vendor before he can finish the PO, so he clicks the button to go back to the Vendors layout to create a new Vendor.

       

      Unfortunately, if the button to go back to Vendors has "go to related record" for the vendors table/layout, it won't go anywhere because there is no related Vendor yet (as the Vendor hasn't been created).

       

      So what I've done to move past that is create a script that has both steps in it:

      Step1: go to related record in Vendors wiht Vendors layout

      Step2: go to layout Vendors

       

      That way, if the first one fails, it will do the second one.

       

      My question is this: Is this the correct way to do this or is there some sort of IF/Then function I should be using to accomplish this?

      It seems to work just fine and doesn't get in the way of anything but I don't want hindsight to slap me in the face not thinking about a potential consequence to doing this.

       

      Thanks!

        • 1. Re: Navigation to related records
          philmodjunk

          With your approach, the record shown on the vendor record will be whatever record currently happens to be the current record. This might or might not pose problems for your user.

          If you want, you can check for the existance of a related record before doing the GTRR and do something different when that is the case. You can open a dialog that reads: "No vendor is linked to this purchase order. Create a new vendor record?" And then the user can choose whether or not to create the new vendor record (perhaps they need to cancel and use a dropdown list or other control to select and existing record).

          You can also do the same check, using get ( LastError ) immediately after the GTRR.

          • 2. Re: Navigation to related records
            BryanN

            With your approach, the record shown on the vendor record will be whatever record currently happens to be the current record. This might or might not pose problems for your user.

            Yup.  No problems for the user at all as they would know they wouldn't be seeing anything related. Cool

            If you want, you can check for the existance of a related record before doing the GTRR and do something different when that is the case. You can open a dialog that reads: "No vendor is linked to this purchase order. Create a new vendor record?" And then the user can choose whether or not to create the new vendor record (perhaps they need to cancel and use a dropdown list or other control to select and existing record).

            You can also do the same check, using get ( LastError ) immediately after the GTRR.

            I actually have a button next to the dropdown/valuelist for the Vendor ID that allows new record creation in the Vendors layout which defeats that purpose of a prompt but it's an excellent suggestion that I didn't know about before.  I may use it elsewhere in the DB.

             

            But based on your answer, my script doesn't have anything inherantly wrong that will mess anything up?

            • 3. Re: Navigation to related records

              Since we can make so many links and so many layouts, its tough to keep in touch with reality...

              Another problem is having disconnections in our chain:

              Customer<>invoice<>LineItems

              We might try to show all of the line items in this link to the customer but it won't work unless we've stored a customer id with the line item record.

              But...if we gttr to invoice and then from an invoice layout gttr to items, we have the related items.

              I have simplified my life kn my new ventures and eliminate long nested relationships with breaks and instead use only one or two tables deep (instead of 20) in one chain.

              Thus I have Customer<>Invoice and Invoice<>LineItems and I can cleanly make the transition above.

              Scripts are also my prefered method of GTTR since I can adjust a script and it immediately is reflected through all 25 buttons on 23 layouts, etc. I don't have to update EACH AND EVERY BUTTON.

              I do have to NAME the scripts so I can remember what they do.

              For Instance:

              GTTR Invoice

              IF(get(scriptparameter) = "Customer" (or I can use get(layouttablename)= "Customer" as the parameter)

               gttr(from customer to invoice)

              Else if (...purchase order )

               gttr(from po)

              else if(...phone numbers)

              gttr(from phone to customer) 
              gttr(from customer to invoice) 

              ...and so on

              Now I know I want to show related invoice records and there's my script that does it so no matter where I am I just perform one script.

              • 4. Re: Navigation to related records
                philmodjunk

                Nothing inherently wrong, but I'm not comfortable with taking the user to a vendor record that is unrelated to the current PO. That might create a false impression that it is linked to the current PO when it is not.

                • 5. Re: Navigation to related records
                  BryanN

                  I hear ya.  The only time they would be looking at an unrelated vendor is during the PO creation - the PO being blank (and obviously unrelated).  Fortunately, I can cover this in our CRM training : )

                  Thus I have Customer<>Invoice and Invoice<>LineItems and I can cleanly make the transition above.

                  I have also done this as well, Trying to keep everything as tight and compact as possible without going ape shit on child tables

                  • 6. Re: Navigation to related records
                    philmodjunk

                    My point is that you can easily avoid this and thus not need to do any training on this point at all. And couldn't you have a partially completed PO, just no vendor selected yet? If that's possible, then this could be more confusing to a new user than you currently are imagining.

                    • 7. Re: Navigation to related records
                      BryanN

                      My point is that you can easily avoid this and thus not need to do any training on this point at all. And couldn't you have a partially completed PO, just no vendor selected yet? If that's possible, then this could be more confusing to a new user than you currently are imagining.

                       

                      I hear ya.  What script would do a check like that?

                      • 8. Re: Navigation to related records
                        philmodjunk

                        There are three different tests commonly used with GTRR to avoid problems due to the absence of related records:

                        Just before:

                        If [ Not IsEmpty ( RelatedTable::Field ) // test a field that is never empty in the related table]

                        Just after GTRR:

                        IF [ Get ( LastError ) = 0 // error code 0 means no errors occurred]

                        And for cases where you use the match found set option:

                        Set Variable [$LayoutName ; Get ( LayoutName ) ]
                        GTRR HERE
                        If [$LayoutName ≠ Get ( LayoutName ) // if no related records, script does not change to different layout specified in GTRR step.]

                        • 9. Re: Navigation to related records
                          BryanN

                          If [ Not IsEmpty ( RelatedTable::Field ) // test a field that is never empty in the related table]

                           

                          So for example, the PO uses a drop down list for vendor ID (it's FK) to select a vendor.  So I would choose the Vendor ID PK for the vendor table as it should never be empty as it's auto serialized? 

                          IF [ Get ( LastError ) = 0 // error code 0 means no errors occurred]

                          When would I use this one?

                          • 10. Re: Navigation to related records
                            philmodjunk

                            Exactly. In fact, the foreign key field is almost always the choice used with this method.

                            The Get ( LastError ) function is an alternative you can use in place of using Is(empty) so long as you put it immediately after the GTRR step. There really aren't any major advantages of one over the other.

                            • 11. Re: Navigation to related records
                              BryanN

                              Exactly. In fact, the foreign key field is almost always the choice used with this method.

                              The Get ( LastError ) function is an alternative you can use in place of using Is(empty) so long as you put it immediately after the GTRR step. There really aren't any major advantages of one over the other.

                               

                              I hear ya.  What i've done is used the no Is Empty as a part of my if / else

                               

                              If [not Is Empty( RelatedVendorTable::VendorsIDPrimary Key)]

                              GTRR

                              Else

                              Custom Dialog "There is no related vendor.  Click ok to be taken to the vendors layout to create a new one..."

                              GTLayout Vendors

                               

                              Bueno?  I used the related PK instead so that way I can use the same script for a bunch of buttons going to Vendors instead of just one instance.

                               

                              • 12. Re: Navigation to related records
                                philmodjunk

                                Looks good to me.

                                (BTW, error codes are something you can look up in FileMaker Help. Some developers use: Set Variable [$Error ; value: get ( LastError ) ] to capture any error code returned and then use a set of If-else If blocks to identify the error message used and display different error messages depending on the exact error code returned--which is where get ( LastError ) can be more useful.)

                                • 13. Re: Navigation to related records
                                  BryanN

                                  Cool thanks man!