storing settings and user preferences

Hi group,


I build solutions that are used by diffrent clients for which I have to
allow different preferences and such. I keep those settings in a
1-record table, each in a different field, and of course also use
globals and vars all over. With a growing table count, the number of
parameters of all sorts also increses in the hundreds.

It's no big deal, but I wish I cound store them as records instead of
fields, so Instead of having 100s of fields in the parameter table, I
could use just a few, such as parameter_ID, name, value, type. Adding a
new parameterr would be just a new record, not a new field.

But I usually access these values through a constant relationship (x),
specifying the field (paramater) I need (parameter::field). Maybe
there's a better way, or some clever trick to access the content a
specific record whithout having to set the record_ID somewhere as a
match field. That is certainly possible, but would defeat the poupose
entirely (get ride of field on one side, only to create 100s on
relationships on the other side...)

Any thoughts ?

Re: storing settings and user preferences

In article <1F75j.25390$9F1.6312@read1.cgocable.net>, MAP
wrote:

> Hi group,
>
> I build solutions that are used by diffrent clients for which I have to
> allow different preferences and such. I keep those settings in a
> 1-record table, each in a different field, and of course also use
> globals and vars all over. With a growing table count, the number of
> parameters of all sorts also increses in the hundreds.
>
> It's no big deal, but I wish I cound store them as records instead of
> fields, so Instead of having 100s of fields in the parameter table, I
> could use just a few, such as parameter_ID, name, value, type. Adding a
> new parameterr would be just a new record, not a new field.
>
> But I usually access these values through a constant relationship (x),
> specifying the field (paramater) I need (parameter::field). Maybe
> there's a better way, or some clever trick to access the content a
> specific record whithout having to set the record_ID somewhere as a
> match field. That is certainly possible, but would defeat the poupose
> entirely (get ride of field on one side, only to create 100s on
> relationships on the other side...)
>
> Any thoughts ?

If they are "user preferences" then the user must have some sort of
name / login, and that can be used for the Relationship link to your
"Preferences" Table.


I don't know what kind of "settings and prefences" you are storing, but
"hundreds" sounds extremely excessive. I would guess that you're
storing temporary data in that table that does not really need to be
kept for the next session. This type of data is best stored in a
"Global" field (usually in the current Table) - each user is given
their own "Global" fields when they connect (copying the data from the
Host computer), so changing the data for User1 doesn't affect User2.
When the user quits from FileMaker / closes the file this "Global" data
is lost for all connected users, and only the changes made to Global
fields by the Host computer are saved.

In newer versions of FileMaker you also have Parameters / Variables
that you can use for such temporary data storage.


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)