How can I generate a wide range of related records in a portal?

[Kip]

I have a recipe dbase, using o.a. the tables:

- "recipes" and the table:

- "search recipes".

Both tables are related by the field "recipe name" (recipe name = recipe name)

In the layout of "search recipes" I have the entry field "recipe name". Any entry entered in this field should generate results in the portal (from the table "recipes")

So I want the entry "tomato" to deliver the results:

tomato soup

spicy tomato pie

tomato soup 2

Or when I enter: "tomato soup" it should result in displaying:

tomato soup

tomato soup 2

I just cannot figure out how to do such a thing with FMPro 9.

[bcooney]

You do not need two tables, and you really don't need a portal.

All you need to do is FIND in the recipe name, and then show results in a list view.

PS: Skill Level refers to your knowledge of FM, not the fact that you might be using FM "Advanced"

[Kip]

duh....

Ofcourse I know you could use find. However, this is not what I want and not what I am asking...

[comment]

A find would be preferable in the described scenario, because a relationship requires an exact match.

If "spicy tomato soup" needs to match "tomato", then "spicy tomato soup" must be exploded into:

spicy

tomato

soup

If "spicy tomato soup" also needs to match "tomato soup", then the exploded field must look like:

spicy tomato soup

spicy tomato

tomato soup

spicy soup

spicy

tomato

soup

and it still won't match "soup spicy".

[LaRetta]

duh....

Ofcourse I know you could use find. However, this is not what I want and not what I am asking...

You are being a bit short with someone who is only trying to assist you. It may not be what you want but I can assure you that (most times) what is requested and what should happen are NOT the same. It is our job to make you aware of the better methods - we cannot see through these posts to know that you've considered finds (the easiest approach). Sometimes we all forget things and/or are too new to understand and/or possibly haven't self-rated themselves accurately. We're human after all ...

The fact that you have a (probably needlesss) 'search' table means that you must go the search layout (table occurrence), type your search criteria, view results in a portal (instead of a list as normal) and then STILL go elsewhere (back to your receipe table) to view the details. So it requires a needlesss table, a complex multi-line exploded calculation, additional scripting and jumping around and will still NOT provide you everything that you want.

Good for Barbara (and now also Comment ) for trying to steer you in the right direction; don't you think? :laugh2:

[bcooney]

I didn't mean to insult you. However, many people here are new to FileMaker and often create techniques that are unnecessary. I felt that you were going down that road, simply because you have an unnecessary table.

As comment explains, portal filtering is too exact for your needs without an exploded key.

[Vaughan]

Y'all missed something important from the original post:

Both tables are related by the field "recipe name" (recipe name = recipe name)

Nudge nudge, wink, wink, say no more! :

[Kip]

Thanks for all the kind input. I realize I'm thrown back to do a search :-)

@vaughan: yep that is the current situation and that indeed results in an exact match, of which I am very aware ;-)

[Vaughan]

What happens when a recipe needs to be renamed: say you discover that there is a typo and it needs to be corrected?

Edited October 27, 2010 by Guest

[LaRetta]

Hi there, Vaughan!

I'm not sure that Kip is requesting the use of recipe in a relationship as a key but rather searching for recipe (or simply displaying results in a portal). But I appreciate you bringing this up for clarity and I DID miss that perspective.

So Kip, if the purpose is to use Recipe name in binding relationships then you shouldn't use it - you should use a unique, FM-generated, auto-enter, meaningless serial number. In this way, if you change the recipe name (as Vaughan is suggesting) then it won't break your relationships.

If you are simply searching through recipe names then a true search would be the easiest because it can produce partial matches and the use of global such as *grape*.

UPDATE: Oh, I meant to say then:

To find 'spicy' or'tomato' in same recipe name, use two separate find requests. To find a recipe with spicy AND tomato in same recipe title in any order then enter Spicy and then constrain that found set to tomato (or vice versa). In this way, the two words can appear anywhere within the recipe even in reverse order. You can also include wrapping words with * so that it will find them if the search words are within other words. It can be scripted for User-friendly handling as well. :laugh2:

Edited October 28, 2010 by Guest
Added update

[comment]

To find a recipe with spicy AND tomato in same recipe title in any order then enter Spicy and then constrain that found set to tomato (or vice versa).

:qwery:

[LaRetta]

:blush2: oh dear. I should have just climbed into bed at 2 am instead of posting.

Thank you for simply bringing my insanity to my attention, Michael, instead of explaining in agonizing detail why my suggestion was bizarre.

Of course, finds are word based and both words can be in same find request and order doesn't matter at all. I had just finished a major project and was high on relief and very short on rest. And now I'm on vacation!