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.
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.
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.
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.
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.
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?
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!
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%.
Sent from my mobile device... Please excuse typos.
Message was edited by: Bruce Herbach
Found some useful info on schema locking. Thought I'd post it here for anyone else that may be curious…
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.