Multiple matches in a Keyword Join Table

[Wickerman]

Hi - I hope this has a simple answer . . . Let's say I have a Film database with a Title table connected to an Actor Table by a join table called Appearances, so that a single film's actors are reflected in many Appearance records.

On the main layout, whose context is the Title table, I have a portal to the Appearances table with, say, 10 slots to enter actors names.

Q: How do I perform a find on multiple names, for example, search for films featuring both Bogart AND Bacall? (When I enter find mode, I only get one field in the portal to enter a name in.)

Thanks!

[Søren Dyhr]

You will continue using the first portal row when entering find mode the second time around, but here choose Constrain Found Set from the request menu:

http://www.filemaker.com/help/Script-Steps72.html

--sd

[comment]

Here's another way to do it, using only stored fields:

1. In Actors, find Bogart OR Bacall (2 requests);

2. Go to Related Record [ from Appearances ; Match found set ];

3. Find duplicates in TitleID [ Constrain found set ];

4. Go to Related Record [ from Titles ; Match found set ]

[Søren Dyhr]

Ah! To avoid the second search -if made at all- behaves considerably faster, but my hunch tells me that GTRR(FS) takes a lot of efford algorithmicly speaking as well!

However, we've lately been spoiled rotten with unindexed seaches working fairly quickly. The good question is which of them behaves best in a networked solution, it has a price to pay when attempting to usher not just one index, which can be cached, but instead two.

Pre fm7 were we squeamishly afraid of unindexed searshes, that we gladly tampered with the clipboard to achieve this behaviour:

http://www.kevinfrank.com/download/multi-gtrr.zip

...hoping to know ways to restore a magnitude of the objects likely to reside there!

Where the convience tilts from method to method is hard to predict, only that the constrained request in unstored fares pretty well until the indexes ushered needs to be chopped up when networking.

--sd

[comment]

I agree. I don't have the facilities to test this properly, but the speed difference is probably not dramatic. I just wanted to point out that it is possible.

Besides, when did you ever use 'Find duplicates' for something other than data cleanup?

[Søren Dyhr]

when did you ever use 'Find duplicates' for something other than data cleanup

I must admit the ingenuity applied is stunning!

--sd

[comment]

Thanks, I like it too. Alas, it won't work for three or more actors.

[Søren Dyhr]

But perhaps we need to think up an ANDFIND that scales both recordnumber independent as well as requestnumber independent, using indexed fields only - it's almost to easy to hit an unstored field??

--sd

[comment]

Been there, done that:

http://www.fmforums.com/forum/showtopic.php?tid/174036/

Perhaps it could be streamlined a little, now that List() and GTRR {Match found set] are available - but it's not going to be simple by any means.

[Wickerman]

Thanks for the rplies -- Somehow after all this time I had never reeally used the 'Constrain' function! I'm also grateful to have the speed issues laid out regarding the various solutions. This place rocks.