A "Find" Revolution ?

[Ugo DI LUCA]

Hi Forum, Gurus and all users,

I need some comments on this please.

Some of you may already have noticed that I have that bad habit to use Relationships for any "sauce".

This will be *double* true for this post...

One major issue I wanted to solve in joining the Forums was to learn how to correctly adress the Relational Diagram issue I had in my own FM business solution.

I started an update, which quickly became a complete rebuild, by maximizing the use of Relationships.

As I started as a developer some month ago, I decided to use my own files as a Visit Card and somehow a "Laboratory" for some experiences.

So here's the point I'd like to discuss in this "theorical area" ...

1. This db, a complete Product-Customer-Supplier-Invoicing is now running with nearly *NO* "Find" scripts. Quite anything get targetted through relationships, global scripted keys and *many* indexed keys and multi-keys for right side. I'm planning the last move. Get rid of any "find" process.

Is this reliable ? Does anyone ever worked on such a structure ?

2. One of the project I'm currently developing probably originated this idea. This client, a great "Find" Consumer, asked as the highest priority for his db solution, that each Find/Match be processed in the minimum time.

I studied with the end-users all their needs in terms of "finds", the criterias they needed to enter, how the result should be displayed,....

Once I compiled the "Find Requests" in a report, I came along with a solution, which I never saw implemented, nor discussed anywhere.

Why not create a Find db , and any necessary right keys according to the criterias needed to be entered !

[ernst]

Hi Ugo,

I think that using relations is great for the most-used select / search procedures in projects like your Product-Customer-Supplier-Invoicing system.

But being able to use what you call 'Plain Find' processes is also handy, for example for 'custom finds'; Filemaker's own Findmode is i.m.o. definitely more flexible than searching using relations.

As far as stability goes I think both approaches are OK.

A separate 'Find' database like you describe can be visually appealing, and thinks like storing the last-used find citeria for every user etc. can be nice features when not overdone...

Best regards,

Ernst.

[kenneth2k1]

I think a find file is an excellent idea. It should offer more capability for detailed searches. As far as speed though, nothing beats Ctrl+F and typing my search.

Ken

[Ugo DI LUCA]

Ken,

I've just spent a long time educating them not to use shortcuts, as Cmd-C or Cmd-V

Ernst,

Thanks for your comments. Actually, if all expectations are met, then even a multi-criteria search involving relationships could be used. It surely brings more work though and constant update when new needs are coming by...

[kenneth2k1]

Ugo:

Yes, that is a good idea for the end user. I know that I have scripted searches in my files, and they rely on switching layouts. But if the user hits Ctrl+F, they may forget what mode they are in. But for me it's not a problem

[Jim McKee]

Ugo ...

My only thought on this is the issue of maintaining the system over time as users' needs change and the system has to evolve to keep pace.

As a client, I'd want to know how much it will cost me to maintain and "grow" the kind of system you've described, compared with one that uses a system built mostly with traditional Find procedures. Will the time savings of a more relationship-based system justify the higher ongoing development costs of such a system? But, I may be incorrectly assuming that a more relationship-based system will cost significantly more to develop and maintain.

[Ugo DI LUCA]

Hi Jim,

Correct, it can be tedious to set up so that it can evolve. That's why it has to be thought and developed with time, many dialogs and "brainstorm" with the users.

I really hope the next versions of FM would allow to target a field and a Value List to be displayed in a dynamic manner, so that it can be done with less work.

Actually, the current solution is running with lots of script steps, associating globals and GetField() functions, as well as an external value list file always used as a "related" value list.

A Classic Find Layout could be kept for those uncoming needs, if the developer has left the building or the investement was too expensive.

Now, if 90% of Finds process are adressed with the first method, it would stay an efficient solution.

Thanks for the input.

[Leb i Sol]

Hi Ugo!

Many thanx for the work shared.....this is a great idea/approach and one of the many 100% needed workarrounds in FM as it lacks the ability to "session" users searches and also gives the "go back" ability when searching....also, have in mind that people are so used to "web style of searching" where 'go back and edit my critearia' is now expected.

Great example would be ( oh yes) searches setup by engines for employments (like monster.com) where users can come back to their searches and simply double check the results....anyhow, thax for the concepts and samples!

Take care!

[Ugo DI LUCA]

Hi,

Sorry, I'm a bit caught by a deadline here, which explains why I'm currently not very active on the Forum, nor reactive to your PMs.

This project came true...

It works like a charm although it doesn't stricly follows my first ideas.

It's a 3 files folder to be added and a few settings to be made to your existing files.

It took me 15 minutes yesterday to succesfully merge it to the latest solution I'm developing.

I'm tailoring a ready-made documented solution. It's 90% ready right now, but I need a few hours to prepare the documentation and finish its translation.

Those interrested to test it when ready could just send me an email at [email protected]

Attached are a few screenshots as well.

This solution would allow you to customize as many finds you want, each with as many requests.

Your users would also be able to create their own, on demand.

You can choose Default or Temporary settings for the result display, either in a Layout from the Target File, or within a Dynamic Portal, both with given sorting keys.

The result of each find can be stored on trigger or daily updated at startup if you need a it.

You can make a selection of the most useful finds, and have them appear instantly by a Menu button.

You'd be able to customize the field names or Layout Names , disallow access to certain fields or layouts according to the user.

Plenty of other useful features...

screenshots.zip