Finding across multiple fields

[misanthropia7890]

Each record contains 5 sample text fields (sample1, sample2, etc). In the search, I want the user to be able to just fill out one box for a sample and during the find, it would find the user request on all 5 sample fields in each record.

I have tried a couple of things including setting sample2 = sample1 and then Extending Find, but nothin seems the work.

Thanks for your help! This has been really bugging me

[bcooney]

So, the match could be in any of the five text fields (as opposed to must be in all of the five text fields)?

If so, create a layout to serve as a dialog "Find_Text". Put a global text field on the layout g_Text. Also put a button "Perform Find" that has the following script attached (pseudo-code)

Go to Layout (one based on the table that you need to search).

Enter Find Mode

Set Field [TextField1, g_Text)

New Record/Request

Set Field [TextField2, g_Text)

New Record/Request

..repeat for each text field that you want to search

Perform Find

[bruceR]

Each record contains 5 sample text fields (sample1, sample2, etc). In the search, I want the user to be able to just fill out one box for a sample and during the find, it would find the user request on all 5 sample fields in each record.

I have tried a couple of things including setting sample2 = sample1 and then Extending Find, but nothin seems the work.

Sounds like a design problem, and figuring out how to search is solving the wrong problem.

Almost always, when there are numbered fields like that, the design should be changed to become relational, in which case the problem goes away because there is only one field to search.

I'd suggest you give us a bigger picture about what this solution is all about.

[misanthropia7890]

thanks, i reconsidered the design of the database and made those sample fields into another table so it will be easier to search from

[Digital Primate]

First of all, I don't want to drag away from the original poster's problem, but I found mine somewhat similar. That's why I'm taking the liberty to tag mine to his/hers.

I too have a DB with ten fields that are similar and interchangeable. They will contain names from on-screen talents.

The plan was for the researcher that's doing the tape spotting, to be able to choose from a (drop-down) list, so that the spelling of each talent's name would be correct.

Then, when we would perform a search, no record would be missed just because the researcher spelt it wrong.

So therefore, the original lay-out/design was to provide 10 fields where the researcher had room to fill in the name or choose one from the list.

Today, while testing, I realized that this is a flawed logic, since the search function only looks in the field you enter the name in.

There's probably 10+ different ways to tackle this, but I'd like to keep it as simple as possible.

[Vaughan]

The answer to your question is the same as that for the OP: use a relational design.

Re-read BruceR's post above.

[Digital Primate]

Could you elaborate on that? I've been searching (and learning) about relational databases and adding tables for the past few hours (it's literally my first three days in FMP) and I can't get my head around how to link this together.

EDIT: I've created another table which holds the names of a few talents already (Table is called BeeVee, its main field is aptly called Names).

In the original table, I deleted the 10 fields, and just hold the original one (Called Bee0).

I then linked both tables in the graph.

Now how do I go from here? How does having a seperate table help my user, who will still want to add several Names of onscreen talents into a field? And how does that help the overal consistency, with the already correct spelt names in a different table?

Thanks (many thanks) in advance.

Edited July 24, 2008 by Guest

[bcooney]

What you need to learn is portals.

When you have a parent-child relationship, you can show all the parent's children in a portal on the parent layout.

Also read up on primary and foreign keys, and auto-entered serial numbers. You do not match parent and child by names, but rather by meaningless, unique numbers.

[Digital Primate]

Thanks - I will!

I found the lookup function - but it is all so ******* confusing - I'm stuck with the dutch version of the software, so a lot english commands and dialog boxes have different names in my version.

Anyway, thx again.