Avoiding Arachnophobia - What about global fields like a search box?

Lounge (Discussions)
1

I've seen H0nza's talk about arachnophobia and have gone into our database and split it up and the speed has increased 5-fold almost instantly.

One thing that's breaking all over the place are user-specific global things. For example:

  1. Search box in top nav
  2. Date range for report search

In the past I had a "global" table and whenever a user connects to Filemaker it would create a new record for them and I'd store these sorts of things there. This allows users to (for instance) search for one thing on their phone and a different thing on their desktop.

All of these are fields that are editable, so they still need to exist as a field, and the search field specifically needs to appear in the top nav of every screen... argh... My brain is melting.

Do I add a "search" field in every table that has a layout with a top navigation (students, staff, dashboard, etc.) that's global? Is there some way to join back to global fields that won't throw a constant "someone else is editing this record" error message?

2

That will not happen with global fields, from Help file:

Global fields in hosted databases

When a client connects to a hosted database, each client’s global field values are maintained independently from one another. This makes global fields useful as temporary storage locations for information unique to each client’s session, such as fields used for filtering portals or lists.

The client’s initial global field values are those that were in use when the file was last closed by FileMaker Pro on a local computer (not via FileMaker Network sharing).

A long time ago I created a global table to put all those global fields, but found out that was not a very good idea. I suggest to create the global fields in the table where they belong. Since the value is set back when an app is open, I suggest clearing those fields on open.

2 Likes
3

@planteg, what was the problem with putting all the global fields into a single table? How did it help to have them in the "table where they belong"? I'm wondering where fields like a search field that appears in a navigation bar would go.

2 Likes
4

You got me on this one !

In the end the problem was finding out which table was using a specific field. This is why I change to put the field in table of use.

5

I happily have a few different tables that are just for globals. There are system globals for developer/app specific preferences. There are UI globals for fields that users interact with, such as inputs like a search field or a complex input form.

There are language preferences.
There are owner/business preferences.
There are user preferences.

These all have to move into a global space. For me, it makes more sense for them to be in one spot. I find it easier to remember where they are.

3 Likes
6

I do the same @Malcolm mentions. In a particular application I'm working in today one Globals table has 125 fields (I just checked). I think about 20 or so fields could probably be moved to a specific table, but I like them all in one place so I know where to go when developing new complex forms or complicated on-demand output. Some of the fields are used in a wide range of contexts or specialized forms on card windows to prepare parameters and variables for scripts.

This is separate from a Settings table and other utility tables I like.

1 Like
7

My mileage also varies on this:

Session related values establishing user settings and app behavior go into one global table the is referenced in every UI-File of the solution. This is also true for search fields and input fields for general purpose dialogs.

Global fields used in custom dialogs are located in the related table or in case of higher usage (or for any other reason) may reside in what I call a work-table only consisting of the global fields mirroring the fields of the table the data is stored in. These work-tables are put either into the UI file or beside the original table in the data file

8

Thanks all. This is really helpful. Is there any risk to mixing and matching globals and settings? For example, I have a settings table where I have my SMTP info for HTML emails. Then I have a Global filed to make the text file that gets set and sent. I see the value of putting it in the Globals table, but it also feels cleaner to put it with the settings that are being called in the script as a Global field in the settings table. That way everything I'm using for my script is in one place.

9

Most of our files have a utility ZZ_Globals table full of global fields. We used that for very temporary generic fields for Show Custom Dialog (will gradually convert to variables), but also specifically-named global fields for use on layouts, etc.
We generally try to avoid cluttering up a normal data table with global fields. However, there is at least one situation where having them IN a data table is necessary: when you want to use them as the local side of relationship criteria coming from this table, whether alone, or in combination with non-global fields.

3 Likes