Looping to a desired sub-set

[sandyinlet]

In FMP6 we could make a list of record IDs and then have FMP go to that particular set of records. How is this done in FMP10?

Ideally I'd like to run a loop that conditionally gathers up these IDs into a variable, set a global field with the contents of the variable, then do a GTRR to that set. Is this the way, or is there something better?

[bcooney]

Your above method would work (although I'd probably just populate the global directly rather than use a $var).

However, can you use a multi-predicated relationship to go related?

[Vaughan]

"In FMP6 we could make a list of record IDs and then have FMP go to that particular set of records. How is this done in FMP10?

Ideally I'd like to run a loop that conditionally gathers up these IDs into a variable, set a global field with the contents of the variable, then do a GTRR to that set. Is this the way, or is there something better?"

Instead of running a loop that goes through the records gathering IDs, use the "found set" option in the GTRR script step and go directly to the related records that match the found set of master records.

[sandyinlet]

Your above method would work (although I'd probably just populate the global directly rather than use a $var).

However, can you use a multi-predicated relationship to go related?

Multi-predicated relationship?? Whazzat?

Here's what's going on. I have a current set of records to go through, setting a field according to conditions. However, at the end of the process I want to present the user with those records that failed to match the available conditions, so that they can now make manual settings.

How would you handle this situation?

Appreciated.

[mr_vodka]

What are you conditions to set the field. Does a field need to be set? Please provide some more information Sandy so we can try to see what the best method would be here.

BTW what Barbara met by multi-predicate here is having more than one criteria in your relationship. For example:

ParentID = ChildID

DateOwned = DateBought

or something else like

ParentID = ChildID

DateOwned <> DateBought

[sandyinlet]

What are you conditions to set the field. Does a field need to be set? Please provide some more information Sandy so we can try to see what the best method would be here.

BTW what Barbara met by multi-predicate here is having more than one criteria in your relationship. For example:

ParentID = ChildID

DateOwned = DateBought

or something else like

ParentID = ChildID

DateOwned <> DateBought

The conditions work something like this. If the default company link is not empty, AND the default company address is not set, BUT the link to company addresses is valid (there are indeed address records but none of them have been set as the default) then do nothing — this being a record requiring end user manual handling. However, if there are no company addresses, default or otherwise, AND there is a personal home address, then use the home address to set the Address.chosen field for that record. Rinse and repeat for setting the eMail.chosen field.

One solution I've thought of since posting this topic is to simply omit the records in which the loop automatically fills these "chosen" fields leaving the user with records which require his/her manual handling.

Comments?

[mr_vodka]

Omitting the ones that you dont need is probably your best bet.

[sandyinlet]

I asked a colleague for his recommendations and here's the three options he gave:

------

Yes, there are lots of ways you could do this:

1. accumulate the keyField values required in a global global field, use a GTRR with relationship globalField->keyField. This is the way we've always done it.

2. you could omit all the unflagged records then do a GTRR with relationship keyField->keyField using the 'match all records in the current found set' setting. This has been available since FileMaker 7(?).

3. accumulate the keyField value in a $variable, go to find mode on the required layout, loop through $variable setting up a find request for each value in $variable. (Available with FMP 10. No relationship required, but more work to setup. Using the new 'setfield by name' and passing the field name as a parameter, you could make this technique generic for any field, meaning that you could use it with any field name and won't have a relationship for any place it is used. Cool, eh? At least I think it should work. I've never tried it. )

All will end up with the same found set.

The preference should depend on which approach is the safest and fastest. Probably #2 is the fastest. I don't see any obvious issues with errors that you could encounter.

You do have to be mindful of things that could go wrong. What errors could you encounter, particularly in a multi-user situation. What is the likelihood you'll run into locked records? Will they affect what you are trying to accomplish (you can't change a record someone else has open)? How do you handle an error if you get one?

I've been trying to think this way for a while, but don't do it consistently.

------

In the end, I'm going with the Omit Record routine, omitting the records that don't need further end user attention. But I'm surprised/pleased to see there are now multiple ways of doing this.

Cheers.

[Vaughan]

The problem with putting record ids in a global field is that there are limits to the amount of text that can be put into a field. That limit is getting bigger and bigger (it was 64,000 characters in FMP 3 to 6, up to 1 billion characters in FMP 7 and later) but it's still a limit that should be trapped for.

Say each record ID is 36 characters long, that allows for just under 28 million records in the found set. That's a limit that some databases might conceivably hit.

The "match all records in found set" option of the GTRR step doesn't have any such limits, so I think it's smart to use a process that has no in-built limitations that will back later come and bite.

[mr_vodka]

In my experience, I find that GTRR (match all records in found set) is much slower than a regular GTRR using a multi-line global field, (which stores all the IDS) on the parent side.