Another way is to dump the IDs in a global text field and use a utility relationship between that global field and the ID field in the target table, then use Go To Related Record to build the found set.
This approach can be faster if you have a lot of IDs, but has the downside that it needs extra TOs and relationships.
Thanks Wim - that's incredible! I hadn't considered using GTRR but it makes perfect sense now I think about it and it's very fast too which is always nice
I really appreciate your help over the last few days.
I've done it both ways and I prefer Find Mode. I don't like GTRR as a script step. There's no way to abstract it.
Can you say a little more about the abstraction approach?
I like abstraction too but if I have a list of Customer IDs I have to go to a layout with the Customer base table in order to build the Found Set so I don't see that there's much difference. For me, the performance gain with GTRR is worth the overhead of more TOs, relationships and dedicated scripts.
I know you didn't ask me, BruceRobertson, but this topic is near and dear to my heart, and I can't help myself.
Like DavidJondreau, we avoid using GTRR just because there's no way to abstract it.
We have a script called "FND__Find" which accepts multiple parameters (we use something like six-fried-rice's method, called "xtag", that I developed before I found out someone else already had).
With those parameters, I can set overall parameters like "dia" (whether to show user dialogs), "pse" (whether to pause for the user's input), "typ" (find, constrain or extend), "key" (the primary key of the record in the resulting found set that I want to "land" on) and more. I can also define one or more req (requests), each with an optional omt (omit) flag, and one or more fld/val pairs.
I had already set it up so that it so if you passed just a list of keys in "val" tags, it'd do a request for each key. (The "fld" is assumed to be the primary key if not specified, and if there's more vals than flds, the script creates a new request to keep setting the last fld.) For short portals, that's surprisingly fast, but it's always been better (as you might imagine) to have less requests.
Recently, I created a "drill down" widget. The widget is actually a field with an arrow image as the background. The field is "utility global" (always blank) from the TO to which you want to user to navigate. Instead of a button, the field has an onObjectEnter script trigger that runs FND__Find.
I've also created a custom function for the "default" FND__Find parameter. The custom function looks at the TO of the field and the TO of the current layout. It uses the relationinfo to find the relationship parameters between the layout TO and the target TO, then parses that and creates a parameter for the FND__Find script. (If the related TO is more than one table away from the layout TO, it reverts to the "list of keys" method.)
What this means is that most times, I can drop this widget on the layout, repoint it to the utility global from the target TO, and I'm done.
As you can imagine, it was no picnic setting up these scripts and custom functions and such in the first place. The payoff, though, is phenomenal. Because we do this and other scripting this way, we usually write parameters, not new scripts. Because we have custom functions for common parameters, we often don't even have to write those.
Great explanation, thanks.
Are any of these function available?
XTags I understand, in principle, having used the SFR function.
"Custom functions for common parameters" though - care to say anything about that?
To each his own, though I'm surprised there's a performance gain. A GTRR is, as far as I can tell, simply type of find. I guess you don't need to create the find requests but that is pretty quick compared to the finding itself.
If you do see a performance improvement, I'd be interested in hearing about it!
Keep in mind a few things about GTRR. If it fails completely, you won't leave the current layout. If you're attempting to make a new window, that will fail too. If you are matching on the found set, and there's no matching record for the current record (but there is for other records in the set) your GTRR will succeed but will throw an error. So, just be careful about error trapping.
Or maybe I'm just not experienced as you guys and am doing things differently (i.e. wrong!)
My issue at it's most basic is that I have a few thousand IDs which I need to create a Found Set from so that I can export that data. At the moment I'm looping through that list a creating new find requests before performing the final search. You imply that this should be at least as quick as what I'm seeing with GTRR so I'm going to look again.
I'm here to learn and so I accept that I'm not always right.
Well; you're surprised by the performance of GTRR because you don't use it.
Way simpler and faster, where the graph is set up so it works, and a relation can be used to go to other instances of the target table occurrence.
Both approaches have significant merits, but the GTRR command has been improved over the years, with the ability to control new window ccnfig, etc.
"a relation can be used to go to other instances of the target table occurrence" That's the part I liked about it. I use the Anchor-Buoy model and find that it's useful to jump between Anchors when, for instance, I'm showing a list of Contacts in a portal and I want to go the detail page of a selected Contact. I can Go To Related Record and switch the layout to one based on a different instance of the target TO, effectively jumping Anchors.
I may be thinking of matching a found set, which, the last time I used it, was terribly slow. Now that I think about it, I have set a global to the current found set and GTRR'd that instead which was much faster. I don't know how it compares to a regular find though. I do mostly single file development and I don't like putting interfaces elements into my relationship graph so I generally avoid it.
Yes, with GTRR it is definitely necessary to test for existence of the related records first. However; this can be tested immediately, before performing the GTRR, by using isEmpty( related::field).
Whereas, with a find, there may be no matching records.
To jurgmay: no, I don't think anybody is saying a scripted find is EVER "at least as fast" as GTRR. It isn't.
It may be fast enough; and the reduced performance may be nearly indistinguishable.