Portal Filtering (AND, not OR)

[rrr]

Let me first see if I can describe a hypothetical in order ask my question:

One file, "foo.fp5", contains records which include, let's say, three text fields: "Name", "Organization", "Hobby" or something like that. In that file, let's define a calc field called "Match":

Match =

Substitute(Name, " ", "

[LiveOak]

The one line answer is that "AND" requires a multi-key, "OR" requires a compound key. An "OR" search would create a key:

Name & Organization & Hobby

In practical application, I usually delimit parts of the compound key with a "-" and set the indexing to ASCII. An example of why is provided by a Building and Unit scenario:

Key = Bldg & Unit

Bldg 1 Unit 11 = Key 111

Bldg 11 Unit 1 = Key 111 oops!

1-11 and 11-1 are much better (set the indexing on the Key to ASCII or the "-" is ignored!)

-bd

[rrr]

Thanks for your reply, though if I read it correctly, I don't believe it addresses what I'm after. I want only one entry field "SearchFor" in which the user can type a term or term(s) which could appear in ANY of the example fields (which themselves could each contain 0,1, or more words), and I don't want the user to worry about entry order (ie: I don't want "Name term must be typed before Organiztion term" in the SearchFor field).

The multi-line key to multi-line key relationship I described in the hypothetical works, functionally and interface-wise, exactly as I want, except that in this case I want exclusive (AND) results rather than inclusive (OR) results.

Thanks.

[djgogi]

LiveOak allready gave you the correct answer to your question.

If you need to allow random order entries in seachField you'll need to anticipate every permutation in rightKey field (in example you gave Match field in related file)

Match =

Name & Organization & Hobby

&

"

[LiveOak]

If you intend to use relationships for your search, it does. The technique is still the same, how the user inputs information and how you create the key (calculations, etc.) is up to you.

"OR" searches use multi-keys, "AND" searches use compound keys.

How you allow the user to enter text in any order and parse it into the primary key needed to match the compound key in the related file is up to you. You might have to look at each word and see which of three lists it occurs in to determine which words in the search to use and in which order to combine them. You will probably need a compound multi-key to allow matches with two or three terms entered. Your compound multi-key for one record might look like:

Name-Any-Any

Any-Organization-Any

Any-Any-Hobby

Name-Organization-Hobby

Name-Organization-Any

Name-Any-Hobby

Any-Organization-Hobby

"Any" could just be a single character to save size. You can now build a primary key to perform "AND" or "OR" searches and combination.

How you allow users to enter keys with abbreviation and spelling errors and still accomplish primary key generation is up to you. Finds are a lot more flexible, but slower.

-bd