Global Finds across Multiple Fields

[LaRetta]

It's me again!

We are using FM 6 and we will be networked. I want each User station to have control over a global field, in which they can input *find criteria* which will active a script (or be implemented via relationship(?)) and search certain fields to find all or partial matches. Then the User will be taken to a list of the resultant found set.

I know I've read about the problems using globals if they are being used to control functions from the Server - that these globals can be overridden by each station? Oh, please bear with me on this ... I have so much to learn

I want each User to be able to enter several partial bits of information, such as Miriam (the Client's first name), 5/21/1997 (Client's DOB), etc. and the search would check the pre-determined fields (hopefully via a checkbox find) and give them instant results!! Okay, okay, I'm a optimist but, with your assistance, I can come up with something very great

LaRetta

[BobWeaver]

In a multi-user system, each user has her/his own set of globals, and so there is no interference between users. The only influence that the server has is this:

1. As the clients open up their files, the initial values of the globals are copied from the server.

2. When a client closes the files, the current values in the globals are lost, except...

3. If there is only one client accessing the server, (ie, the last connected user), then when that client closes the files, the values of the globals on that machine will update the values on the server. So, the next time someone opens the files, those values will be everyone's new initial values (as in item 1 above).

The upshot of this is that you should not depend on globals having predictable values when you open up a file (you may want to initialize them with an startup script). (The exception to this is where you are using globals to hold semi-permanent configuration data, like your own company name, address and logo that appears on layouts, but which the user can't change because access to the field is disabled.)

In any event, there is no problem using globals to hold values temporarily while the files are open.

So, if you want to have a user enter search values into globals, and then perform a find on some fields, it should work fine

[Razumovsky]

Bob,

I think you just answered a question of mine, but wanted to check.

I recently updated a databse for a client to print a truck loadlist using a

go to related records(showall) script based of the selfjoin relationship g_date::_date to get the correct found set.

the first time he did this, it printed the previous days loadlist, but had the correct date in "'Loadlist for <<g_Date>>" at the top.

He called me in a panic- but when he tried it again it printed just fine.

Your post gave me a clue, Does this sound probable:

the previous date was in the g_date field on startup.

He had not exited the g_date field/record when he pressed the script button (I always thought that pressing a button would automatically exit a field) leaving the g_date as the previous date, but during the script the record/field was exited so the correct date printed for the incorrect list?

Has not happened again so far, but still made me nervous.

BTW- it is a single user solution.

Sorry to hijack the thread, but it may be relevant to initial question.

[LaRetta]

Hi!

I'm glad you brought that up, because one of my concerns was whether to leave a previous User's entry in the global or always clear it for the next person or prepare for the next find request(?).

LaRetta

[BobWeaver]

Just for neatness and to avoid confusion, I would start out by either clearing the globals or else initializing them to the most popular choice (such as today's date in a date field etc.).

[LaRetta]

Hi Bob!

Thanks for your help on this. I'm beginning to learn to *leave things tidy* as it saves in the long run. For instance, importing what I thought was All Records from another dB, only to find out I had left it on a 'Found Set' and I didn't import them all

From a Users standpoint, I would think they would prefer to be presented with a blank find request with, as you suggest, a default date. I appreciate your input.

LaRetta

[DykstrL]

To further what Bob said concerning globals - For all of my files, whether single-user, multi-user, or server-hosted, I always start and end with a known clean slate. I run a script that does all of these both on opening and closing:

Clear all variable globals. (globals that hold predefined data, such as multi-state buttons, or logo containers would not be cleared)

Show all records.

Then script any user finds or global sets as needed.

If a file is going to be on a FM Server, also make sure all the variable globals are cleared just before you close it and place it on the server for hosting. You should also do this if you take the file off line to do some tweaking that can't be done while on line. For all of my server-hosted files, I create a script to do this for me that I can run just before putting it on a server or putting it back on line.