8 Replies Latest reply on Jan 17, 2014 2:23 PM by flybynight

    GTRR on Windows going to first record in existing table… sometimes. FM12

    flybynight

      I have a couple places with a pencil/edit button that will take a user to a detail layout for a related/child record. I'm doing this with a button that just does a GTRR (not calling a script). Depending on the circumstance, sometimes it does it in the same window, sometimes it does it in a new modal window. I always have "Show only related records" and "Match current record only" for these. Works great on the Macs all the time. Works great on Windows… most of the time.

      For one of my Windows users, occasionally (like once every day or two) it doesn't work. It appears that instead of performing the GTRR, it instead does a "Go to [First]" record in the same layout. So they expect to go to a detail or purchase order for job X, but instead they are suddenly looking at job A.

      Here is a screen shot of my button setup:

      Screen shot 2014-01-16 at 3.29.16 PM.png

      Anyone else experience this? The solution is hosted on Server 12 and clients in FM12 on Mac and Windows.

       

      Thanks!

      -Shawn

        • 1. Re: GTRR on Windows going to first record in existing table… sometimes. FM12
          Stephen Huston

          If this is being handled with a button which is running the GTRR SCRIPT STEP rather than running a separate script, the specific button in question may be setup with the last radio-button choice: Match all records in the current found set. That sounds like the behavior described.

          • 2. Re: GTRR on Windows going to first record in existing table… sometimes. FM12
            flybynight

            As I stated in the post, and seen in the screen shot of the button setup, it does have the "Match current record only" choice selected.

             

            Additional info…

            But, I found out today that for that same user, it's not just with the GTRR buttons. It happened to her just by selecting a different tab on the layout. This is just a normal tab control, with no script triggers. In this example, the user is on record 45 of 88 found, clicks on something (GTRR button or a tab control that I know of so far), and boom… she's now looking at record 1 of 88 in the found set.

             

            It makes no sense to me.

             

            The typical workflow is that they click on the Schedule button to see the list view of current JobTickets, maybe do a sort, then click on an edit button to go to the detail layout for that JobTicket.

            I'm pretty sure I could eliminate the behavior by adding a couple of steps to isolate that record, rather than maintaining the current found set. But it still doesn't make sense and I would rather figure out why it is doing this, than to put in a work-around.

             

            Laters,

            -Shawn

            • 3. Re: GTRR on Windows going to first record in existing table… sometimes. FM12
              wimdecorte

              Is the database under active development at the time?  A schema lock could produce the results that you describe.  If you do an error check right after the GTRR, the error code (if any) would be useful.

              • 4. Re: GTRR on Windows going to first record in existing table… sometimes. FM12
                BruceHerbach

                Hi,

                 

                I get the same thing if I do a committ record just before doing the GTRR.  Somehow this can lose the selected record in a portal.

                 

                My solution is to pass the ID of the record to the script as a parameter.  When I arrive on the new layout/record,  compare the IDs.  If it is the wrong one,  then "find" the record I want.

                 

                I have tested this a few times,  if I pull the committ record step out,  I always land on the correct record.  The catch is I sometimes end up with a record lock if the user was clicked into a field in the record or in the parent record at the time they tried the GTRR.    Depending on what I am doing and what the user will be doing on the new layout,  I put the committ in or not.  Since this is all scripted,  I can verify that I am on the correct record. 

                 

                 

                HTH

                Bruce

                • 5. Re: GTRR on Windows going to first record in existing table… sometimes. FM12
                  flybynight

                  Ummmm… yeah, that's a distinct possibility. I tend to tinker.

                  Which actions will produce a schema lock? Is it anytime Manage Database is open? Or is it more granular, like being in the same table (define fields), looking at the relationship graph, etc?

                   

                  But lately, I'm not doing much of that… I am working on other layouts. The ones I'm working on, no users have access to right now, so I didn't think I could mess things up that way.

                   

                  If the user experiencing the issue is on FMP, not Advanced, how do an error check? Will this show up in the server logs? Or do I have to add something in a script to trap for the error?

                   

                  Thanks!

                  -Shawn

                  • 6. Re: GTRR on Windows going to first record in existing table… sometimes. FM12
                    flybynight

                    Bruce,

                     

                    That makes sense to me… but in my case, I'm not calling a script. My button is just directly using the GTRR script step. So I don't have a Commit step in there.

                     

                    There are times when I have it doing GTRR in a new (modal) window, that the user does get the message about not being able to edit the record because it is open in another window. This too, isn't consistent. It usually works fine, but sometimes does not. And when it doesn't work, just trying again "fixes" it.

                     

                    The most frustrating thing is an intermittent problem!

                    Laters,

                    -Shawn

                    • 7. Re: GTRR on Windows going to first record in existing table… sometimes. FM12
                      BruceHerbach

                      Shawn,

                       

                      You might have a committ if the user was in a field in another portal row or the parent table and then clicks the button on a different row.  I believe that clicking into a field and then clicking elswhere on the layout tells FileMaker to committ the record.

                       

                      For the most part I always script complex items like GTRR. It avoids having trouble shoot things like this and provides a better user experience.

                       

                      I agree it should work 100% of the time but as you found out its only 98%.

                       

                      HTH

                      Bruce

                      Sent from my mobile device... Please excuse typos.

                       

                      Message was edited by: Bruce Herbach

                      • 8. Re: GTRR on Windows going to first record in existing table… sometimes. FM12
                        flybynight

                        Found some useful info on schema locking. Thought I'd post it here for anyone else that may be curious…

                         

                        http://www.skeletonkey.com/filemaker_schema_locking/

                         

                        http://www.dbservices.com/articles/working-on-a-live-filemaker-system

                         

                        The 2nd link says that a table won't lock if you are using Get (UUID) instead an auto-enter serial #. Curious, but doesn't reall say what other issues you might run into. Not to mention having to do a whole lot of re-tooling of all my ID and match fields to work with UUIDs.

                         

                        Unfortunately, the constrains of our situation often mean that I do have to work "live" on any changes or updates.

                         

                        Laters,

                        -Shawn