Jump to content

Multiple matches in a Keyword Join Table


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

Recommended Posts

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ]

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 5986 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.