Jump to content
Sign in to follow this  
Wickerman

Multiple matches in a Keyword Join Table

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!

Share this post


Link to post
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

Share this post


Link to post
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 ]

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

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