Hi,

The need for Search procedures did evolve according to Database storage capabilities.

If Relational design obviously offered efficient ways to store and access data, automizing searches and multi-criterias Finds is still complex to build.

You probably already developed some dynamic search interfaces, specially when the Database is used as a Data Bank. As long as there is no need to keep the criterias, global fields would be your allies, and there is nothing you should be worried about.

If you were requested a solution where a set of Multi-criterias Finds Procedures could be dynamically called by the user, you

Hi Ugo!

Thanx for this article it is definetly is good guide for "us" trying to venture into more complex solutions.

too bad globals & calculation fields can't be indexed for that Self[relationship]...yet I can see the madness IF they were ...perhaps "stored globals" is what would be usefull.

I really like your idea of external files and use of globals that can be "flushed" ...I guess in a sense making a "temp. stored sessions" or "stored procedures of finds"

thanx for sharing...I am sure I will refer to this article in my later Find Attempts!

Hi Ugo,

I just posted a sample solution similar to this yesterday. I searched the forums, but i didn't browse them so i didn't know that you had recently talked about this same thing. My solution is different than what you are talking about. There is a lot of work to be done either way and mine is probably a little less robust and versitle.Check it out and let me know what you think please.

Hi You 2,

Well, it is easier to implement than to explain.

Actually, I had a sample built extracted from one real solution, but as it used both the relationship way and the classic Find Mode, I thought it could be confusing to post it as such.

Yours is very close in its approach, and would surely fit 90% of any need. It deals with multiple criterias in a "One request Find", while what I suggest could answer a Multiple Request Find, involving Multiple criterias.

That's what explains its complexity, which when implemented, could become its strength.

I'll attach a Light version with only the "Classic Find" method, as soon as I get a chance to.

Be well.

The Separation Model Revealed, an article in the Jan. 2004 FileMaker Advisor magazine by Wendy King and Colleen Hammersley, will be of interest to anyone working on this. Their demo is quite eye-opening. Unfortunately, you have to be a subscriber to get it. With their approach, the Find requests are created through a controlled interface, so it's not a problem to store omits or anything else.

That's interresting...

Can we buy a separate article ?

I'm wondering though. I can store any omit step with the method outlined. I'd just run separate script for omits. Is that what is done there too ?

Thanks