Constraining is easy, extending not so much.

[cmcfarling]

I've been trying to come up with an elegant solution to the following, without much luck. If anyone wants to ponder this and give suggestions, I'm all ears.

The concept is simple, I want to do a search, constrain the found set, and then extend the found set back to the original search results.

Let's say my search returns the following records:

JOB#  SUBJOB#  SEVERAL_OTHER_FIELDS

-----------------------------------

123   0        data

123   1        data

123   2        data

124   0        data

124   1        data

125   0        data

126   0        data

126   1        data

 



I want to then constrain the found set to show only records with a SUBJOB# of 0. So it would look like this:

JOB#  SUBJOB#  SEVERAL_OTHER_FIELDS

-----------------------------------

123   0        data

124   0        data

125   0        data

126   0        data

That's the easy part. A simple "Constrain Found Set" in a script can weed out any records where the SUBJOB# is >0. Getting back to the original found set is where I'm stuck. Using the "Extend Found Set" script step (eg. Find records where SUBJOB# is >0) won't cut it because it returns more records than just the ones in the original found set.

In a sense, this is a "How do you save a search request" question. None of the solutions to that problem, that I've seen, seem to be very appealing. I'm interested to hear some approaches other people would take at this problem.

Thanks

Chris M

[Oldfogey]

This is OK for not overly large DBs.

In almost every file I create there is a field called 'Marker' and two scripts - Set Marker and Clear Marker.

Set Marker uses Replace (or a loop if shared DB) to set the value of Marker to 'X' in the found set. Clear Marker sets Marker to null for the whole DB. (I'm a pessimist and don't trust computers, otherwise I'd just do a re-find of Marker='X' and just clear them.)

That way you can always(?) get back to a particular found set.

[-Queue-]

If your solution is multi-user, using a marker is a bad idea. A better idea is to store the found ids in a global and create a relationship from the global to the id field. When a find is performed, you then go to a layout containing only the id field and use the Copy All Records step, then go to a layout with the global and Paste into it. When you want to return to this found set, you simply use a Go to Related Record [show only related; "global_to_id_relationship"].

This, of course, requires the find to be scripted.

[cmcfarling]

Queue, that sounds like the best bet. What about scalability with that method? What if down the road I'm copying 5000 or more values and pasting into the global field?

So, two issues in question...copying/pasting 1000's of values and using a 5000+ multi-key field for a relationship. Am I asking for trouble?

[-Queue-]

FM 7's text field limit is 2GB, so I don't see a problem unless your id is 200,000 characters.