I have an inventory table that will have thousands of records in it. There is a calculation field named "Available" which is the current inventory level of the product. When that value is negative, it flags the product to be purchased. I import the flagged records into a temporary table to work with. My question is; Is it faster (better?) to use the "Perform Find", or the "go To Related Record" script step? I have used both in other situations, but never with so many records involved.

Hi Flappy:

In an abstract sense, a Relationship is a Find. When we create a relationship, we're building a structured or permanent Find.

For a table with thousands of records, I don't believe you would have any problems with GTRR schemes. My hunch is that it's faster than traditional finds, particularly if it's in a multi-user environment.

Just some thoughts ... :twocents:

In addition, one can use GTRR then Extend Found Set[]. It is quicker than straight find with second Find Request for different criteria (at least when applied to 500,000+ table). But Extend Found Set[] has limits, 1) you can't omit the Restore (Find Request) and use Set Field[] instead (like you can a regular Find) so the Find Request is limited to static criteria and not open to calculation criteria (you must create the calcs) and 2) if you don't specify the Find Request (Restore) then it grabs the last 'used' find request. This can be good and/or bad - I've used it a few times intentionally.

Example: I have 580,000 LineItems. If I'm in Customers and want all that Customer's lineitems, but NOT their invoices paid in full but ALSO Credit Memo LineItems of theirs (that haven't yet been attached to an Invoice), I can STILL use my existing base relationships. So I won't go to LineItems and perform a Find. Neither will I GTRR from Customers directly to LineItems. Instead, I'll GTRR to Invoices (base relationship), Constrain to Balance > 0, GTRR to LineItems (base relationship), then Extend to include Restore (CustomerID and Invoice = 0). Straight GTRR is fastest. GTRR then Extend/Constrain is almost as fast (and allows using prior Find criteria but eliminates calc on the fly) and Finds are slowest (although greatly improved in 8.03 - I haven't tested 8.5 yet).

I envision this process as following the major highways then taking shortcuts across pastures (Extend/Constrain). It's like building your road as you are driving - the graph is the map in your hand. But I no longer build freeways just because I need a GTRR (I used to). I just use what I have with my base relationships (unless I need high-function portal) ... less road construction that way. This method of GTRR - pick up more records (using Extend[]) then GTRR again (and even Constrain[]) is lighteng fast and it saves oh-so many table occurrences.

A benefit of Finds however is that standard Finds are more flexible; FileMaker throws open the doors on possibilities and configurations. It's an intriguing subject; one I would like to study further and shall when I find the time.

LaRetta :wink2:

Extend Found Set[] has limits, 1) you can't omit the Restore (Find Request) and use Set Field[] instead

Can you explain this further? AFAIK, you can either hard-code static criteria, or use whatever is in field/s. I don't see any difference here between Perform Find[] and Extend/Constrain Found Set[].

Thank you for your reply. It has always seemd to me that GTRR was faster, but I guess I just needed to hear it from someone else. Also thank you for your road map analogy. It helps me visualize what I am doing. The conversion from 6 to 7/8 has been fun, and challenging, and at times bewildering. Thanks again.