Jump to content

extend found set behaviour


This topic is 6451 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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?

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 6451 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.