First, save the desired record's RecordID in a variable. Then there are basically two ways to do this:
1) Go to the first record, start a loop. Loop over the records until you hit the one you're looking for.
2) Faster, and therefore more likely better, is a binary algorithm. Works basically like this: Go to the middle of the found set. If the RecordID of that record is greater than the saved RecordID, back up to the middle of the first half. If not, go to the middle of the second half. Lather, rinse, repeat until you arrive at the correct RecordID.
I used the loop and it worked fine (small, <600 records)
Thanks for the nudge in the right direction.
I am curious why you wouldn't/couldn't use the "Go To Record" script step after capturing the record that you want to return to? Rather than sequentially go looking for the same thing?
I tried that idea.
The problem is that after I 'find' the Active Members, the recordID in the found set changes, so if I 'goto' the variable, it is likely to be a different record.
What was easy and accurate is to loop through the found set looking for the $$PKey variable which holds the Primary Key of the selected record.
Slight correction: The record number changes with every found set. The RecordID is internally assigned and never changes over the lifetime of the record.
Right answer. Wrong variable.
I ended up using the PK anyway..... I think it is the same idea.
If you are using FileMaker 13, this is an excellent chance to take advantage of the new "List Of" summary field.
Define a summary field ListOfPK.
No need to display it on a layout.
This returns the list of the field you point it to, for your found set.
Then you need to store the record ID in a variable as previously discussed.
Then you just need to figure the position of the record ID in the list.
Say it is value 37.
Then you just go directly to record 37.
ListOf_focus.fmp12.zip 111.1 K
The 'Go To Record' did not work for me. On this solution - the record numbers change from search to search so it never worked. I had to a Global Var as 'the sticky record' ID and then search for that. If there is a better solution i would love to try it as i fear that this might be extra tasks and search resources that are not needed.
1. Read the suggestion again.
2. Try the attached file from my previous message.
There is a much simpler way to achieve this.
Once you have found your related set of records, which includes the record you want to 'Focus' on (whose PK you have already stored in a global), then you can GTRR based on the relationship to the Global, but you must leave unchecked both of the buttons 'Match with this record' and 'Match with all records' at the bottom of the GTRR dialog box.
This will not change the found set, but will focus on the required record.
Just what the doctor ordered!
Best wishes - Alan Stirling, London UK.
Now THAT is cool! Thanks, Alan.
Fire up the Tardis …
This is excellent! So far I can only test locally (no v13 server available) so WAN performance may differ, but locally, it's fab.
First, I imported approx 270k records into the sample db, to give it a bit more to chew on. (Previously only 1k records). I also changed the Length field to a calc, to make it work a bit harder. Superfast!
Then, I grabbed an old file - a very ugly old file. It's a db that was poorly designed in around v4 and has since been through a few drag and drop conversions. It has around 270k records. Added the v13 Listof summary field and the two layout triggers. Performance just as good.
This is a happy addition to the v13 toolkit.