Restore found set after performing another Find

[Rich S]

Howdy, howdy:

I use the "TOG" method to save a found set (https://community.claris.com/en/s/question/0D73w000006YjbYCAS/detail ) , but I must be missing something: If no records are found, and I perform the Restore part of the script, the original found set isn't restored. How do I restore the original found set after a failed Find?

As an aside, I read elsewhere about creating a Summary field (List of record IDs) to create a list of primary keys to use later to restore a found set, but I don't know how to make use of it to restore a found set. How to?

As always, TIA for your help!

Rich 

Edited December 4, 2023 by Rich S
Minor correction

[comment]

1 hour ago, Rich S said:

If no records are found, and I perform the Restore part of the script, the original found set isn't restored.

I am not able to reproduce this behavior.

 

1 hour ago, Rich S said:

I read elsewhere about creating a Summary field (List of record IDs) to create a list of primary keys to use later to restore a found set, but I don't know how to make use of it to restore a found set. How to?

If you put the list in a global field, you can then use a relationship matching the global to the primary key to go to related records.

 

I am not sure what exactly you are doing (and why), but perhaps you could simply open a new window before performing a new find? Then you will be able to return to the previous found set just by closing the new window.

 

Edited December 4, 2023 by comment

[Rich S]

A new window. Capital idea! I'll give that a shot in the morning. I'll also give the Summary field/Global field a try as well--it's good just to learn how things work, especially in a pinch.

[Søren Dyhr]

On 12/5/2023 at 12:15 AM, Rich S said:

A new window. Capital idea! I'll give that a shot in the morning. I'll also give the Summary field/Global field a try as well

Or ....use both, since the ExecuteSQL does not know of found sets, you often gather a list of ID's in a $$ variable, and loop thru each ID building native request upon request and make a final perform find. Using a new window and issue say a selfjoin GTRR(FS) in it, and then stuffing list of summaries into a $$ could mimic this approach ... by remembering to close the extra window just in time.

--sd