I'm using the extend found set script step to do the following:

go to layout a

perform find

go through each record

set a variable based on each record in the set

count the number of results

go to layout b

write some data

go to layout a

extend found set

start from previous result count

go through remaining records

set a variable based on each record in the set

count the number of results

go to layout b

write some more data

...etc

however, extending the found set seems to sort the records somehow, even though they're "unsorted". the problem is, I can't page through the results in each iteration because i don't know which ones are "added" each time. the end result is that i end up missing some records and duplicating others.

Is there a way to do this correctly, preferably without writing anything to the found records?

Yes, "unsorted" actualy means "sorted by creation order". Perhaps if you'd clarify the purpose of this elaborate exercise, a better method might be found.

ok, well it's complicated, but let's just say i have two fields, red and blue. i want to search for the phrase "alpha" in both. If alpha is found in red, then it doesn't matter if it's also in blue on a given record. but, if alpha is only found in blue, that's a different matter (likewise if it isn't found at all)

but, if alpha is only found in blue, that's a different matter (likewise if it isn't found at all)

This isn't very clear. What would be desired here?

If you can spell out all of the possibilities, this can likely be done with multiple criteria in one Find operation. For example, if you have records:

Record#  red    blue

1        alpha  alpha

2        alpha  

3               alpha

4

Which records do you want your Find to result in?

In that case, i'd want to first find records 1 & 2, and then 3 separately.

I forsee two possibilities:

1- I do multiple find requests, first for any instance of alpha in red, then for !alpha in red & alpha in blue.

2- I use a variable to set which record keys have already been scanned, and just do a fresh search each time, skipping those that are listed in the variable using a filtervalues calc.

I'm reluctant to use 1. because I read somewhere that using ! is not very reliable(?). And I'm worried that 2. will impact performance for large recordsets or complex/multi-tiered searches.

To find records 1 & 2, search for "alpha" in Red field. To find 3 (but not 1 & 2), make 2 requests: one that finds "alpha" in Blue field and one the omits "alpha" in Red field.

My question was more regarding the rest of the process - scanning records one by one is sometimes inevitable, but never efficient.

that seems like a sensible approach, thank you.

with regards to the process, the complete script actually creates a new record for each "hit", so i think scanning each record is inevitable in this case.

actually, since you mention it, is there an easy way to create a list (e.g. of key field values) from a found set without looping through each record?

I believe the new List() function does exactly that (I haven't found the time to play with it yet). If not, you could use a custom function with GetNthRecord(), or the old method of going to a layout with only the key field and Copy All Records. But why do you need to create records, when you already HAVE records?

well, the reason why is complicated, if i get a chance later i'll go into it, it's to do with ranking things based on other things.

Anyway, your suggestion for find requests works, but unfortunately not for dynamic/user-specified find requests, unless there's a way to create a find request that uses variables?

As for the list function, that works perfectly as long as you have a relationship established. I like the copy all records suggestion though

a way to create a find request that uses variables?

Enter Find Mode []

Set Field [ Table::Red ; $variable ]

Perform Find[]

What happens when the List() function references a field in the local table?

Enter Find Mode []

Set Field [ Table::Red ; $variable ]

Perform Find[]

I meant as part of a Perform Find[Restore] step. There doesn't seem to be a script step to "omit found records within current set", so it's back to using the ! I guess.

What happens when the List() function references a field in the local table?

It just gives you the current record data, rather than the found set.

You cannot use variables in Perform Find[]. But you CAN switch a request to omit, by using the Omit Record script step.

great tip, thanks