Preferences Table - Relating to ALL tables in the DB

[David Garza]

Hello,

You guys are an excellent help. When I have a question, I simply run a search and find the answer in less then 5 minutes. This one, however, I can't seem to find. Maybe someone could help.

I have setup a table called 'Settings' to store windows sizing etc. The problem is pulling the data to set Window Sizes, etc. I have one record in the 'Settings' table that will hold everything, but I don't know what is wrong.

I currently have 'Settings' related to 'Interview' via a field called 'Constant (in both Tables) which contains the value of 1. I can do a lookup without any problems there. I've tried the same thing with other tables, and found I did not have the same results.

I've recently found that Global's don't store for a Multi-User environment or a new session either. Silly Me!

[color:black]

Thanks again and God Bless!

David Garza

[Ender]

Hi David,

Do you want the Settings table to remember separate settings for each user from session to session, or is it only to remember what the settings are for the current session?

[David Garza]

Hey Ender,

A mixture of both remember settings, not for a specific user, within every session.

Thanks and God Bless!

[Ender]

Sorry David, your needs are still not clear.

In the case of remembering settings for each user, a User table is used. In the case of remembering settings for the current session, a table of globals can be used. The relationships for using the table of globals is very simple; just link each table occurence group to the table of globals via a cartesian join (X operator.)

The relationship to a User table requires one more step: an additional link from the global table to the User table by User ID or account name.

[David Garza]

Hey Ender,

I want to store the settings for future use for the current and future sessions that can be pulled from any table in the database. Doesn't matter the user.

Basically, a regular record in a Settings table that I can lookup or pull from for use in scripts.

I think I want to use the cartesian join, but I tried that and I am not sure where to relate that to and from and what fields. I tried different variations and none worked.

Thanks and God Bess!

David

Ps. Here is a picture of what my relationship with the certesian looks like.

Edited January 3, 2006 by Guest

[David Garza]

Ok... I am dumb-founded. I played with it a tad bit more and found that I had to have a self-join relationship and then found it worked with a cartesian, but before that it didn't work.

Why would that be?

Thanks and God Bless!

David

[David Garza]

Ok, thank you. I've figured it out. You must use the actual table occurrence that is related to the table you are running the lookup from. DUH! Ok, sorry for wasting your time. It works!

Out of curiosity, is there anyway around this?

Thanks and God Bless!

David Garza

Edited January 3, 2006 by Guest

[David Garza]

One other question; can I have global fields in the Settings table and then have regular fields which will hold the data and then the global fields that will always load whatever is in the regular non-global field and then pull that?

Thanks and God Bless!

David

[Matt Klein]

You can do all of this without the need for relationships at all by using global fields. You do not need a relationship to a table to access global fields. I use the following method for all preferences and icons in my solutions.

In the table you have setup for preferences, create a global field for each non-global field and set the global field to be an auto-enter calculation whose calculation is the corresponding non-global field. Then, create a layout whose table is the preferences table and put all the non-global fields on this layout. Lastly, write a script that you can run at startup/log-in that goes to this layout and sets each of the fields on the layout to itself. It should look something like this:

Enter Browse Mose[]

Go To Layout[Preferences(Preferences)]

Go to Next Field

Set Variable[$field_First, Get(ActiveFieldName)]

Loop

Set Field[Get(ActiveFieldContents)]

Go to Next Field

Exit Loop If[Get(ActiveFieldName) = $field_First]

End Loop

By setting the non-global fields to themselves, the auto-enter calculations in the corresponding globals are triggered and thus the globals are populated to their non-global counterparts.

By using globals for preferences and icons you can access the data in those fields on any layout, in any script, in any calculation, in any file regardless of the focus. All you have to do is make sure that their is a Table Occurence on your Relationship Graph for the preferences table. There is no need to draw relationships to the preferences table.

[comment]

An interesting method came up on another forum:

For each (regular) preference field, there is a GLOBAL CALCULATION field set to equal the regular field.

IIUC, this combines the best of all possible worlds:

1. The global calcs are accessible from any table without a relationship;

2. The global calcs, being in the same table as the real preferences, update instantly without a script;

3. The real preferences can be modified without shutting down the service.

[David Garza]

Sounds like a good idea. That is the questioned I had asked too:

"

One other question; can I have global fields in the Settings table and then have regular fields which will hold the data and then the global fields that will always load whatever is in the regular non-global field and then pull that?

"

But you guys confirmed that this will work. Will this work in all cases?

Thanks and God Bless!

David Garza

[Thomas Seidler]

greetings folks,

i like very much the logic of the preferences table, and the refinement of the calc field. very simple and tight. easy to get the data anywhere.

i'm just transferring from FMP5, and whilst there i obtained this same functionality but also needed every file in a multifile solution to be able to read/write the global data.

To do this i set up my preferences table with a field of value "1". Every other file had a global field also equal to one, and thus the relationship from all the files to this one file was formed. So I could read or write via this relationship whether in 'find mode' or whatever.

Now it seems your current solution does not allow you to write, only to read. I imagine there is no 'neat' (i.e. not having to create a relationship between every created file and this 'prefs' file) solution to this problem? But I write in hope!!! Or at least that FileMaker might consider our need and problem themselves!

Truly global (system wide) globals as well as local (machine specific) globals are invaluable.

Am I speaking rubbish cos of my FMP5 environment and in FMP9 it's just no longer a problem? If there is a simple solution, I've missed it, cos I've been playing around with FMP7 & 9 for a while now, so I await gracious illumination on this subject! :

Cheers, and blessings,

tom

PS the reason i like to have variable i can edit is for passing much data about from table to table, script to script when necessary - easily and simply. While the ability to send variable with 'perform script' may resolve some of the situations, it will not fix all my problems...

[mr_vodka]

i obtained this same functionality but also needed every file in a multifile solution to be able to read/write the global data.

If indeed you are using a preferences table, then I dont see why you would be writing to this table from every possible TOG anyway.

Your users should not be modifying the preference table regularly. Since it is only one record, if one of them in in it, it will stay locked until they commit the record and no one else can access it.

Now if you are talking about a user specific SESSIONS table that is something different. You can have each user with their own record and their settings there.

To do this i set up my preferences table with a field of value "1". Every other file had a global field also equal to one, and thus the relationship from all the files to this one file was formed.

You no longer need a constant field in all your files anymore. You can use the cartesian product 'X' join to relate all the records from one to the other.

Now it seems your current solution does not allow you to write, only to read. I imagine there is no 'neat' (i.e. not having to create a relationship between every created file and this 'prefs' file) solution to this problem? But I write in hope!!! Or at least that FileMaker might consider our need and problem themselves!

Yes data in globals can be accessed regardless of which table occurrence you are at. It does not have to be related. However, as you said, you can not write to the global fields in an unrelated table occurrence. Therefore, you would have to create a cartesian join relationship to the table occurrence of where it resides.

That being said, coming from the world of fp5, you will need to change your perspective of relationships and tables. The Relationship Graph is not a direct translation of the relationships of the fp5 days.

Look into the anchor buoy, squid, etc. models. Having multiple table occurrences is not a bad thing.

[Fenton]

However, as you said, you can not write to the global fields in an unrelated table occurrence.

Of course you can.

[Thomas Seidler]

looking at it, i see they've added 'relational operators' and i could add 'x' which would prevent the need for a dedicated field in each file to 'establish' the relationship...

===

sorry when i posted that, it showed me there had been replies - many thanks, light is coming!

so we have a prefs & sessions file:

• 1 set of fields - text, num, etc
  
• 1 set of calculated global storage fields to mirror the above (enabling universal instant access)
  
• 1 set of global variables to store local user stuff, which as Mr Fenton pointed out can be written to w/o relationship
  
• 4 the extra mile: if i want writeable system wide prefs i need to go the extra mile (made slightly easier now) and make a relationship with each file using relational operator 'x' to create a cartesian join

thank you most illuminating. Perhaps i shall not go the extra mile since it'll make the beast more ugly, and will seek (most probably) to amend my scripting tacks instead…

[color:green]

Many thanks [color:blue]Mr Vodka & [color:red]Mr Fenton (cos you were both right! I think…!!? - just one was talking about system wide, the other machine wide - but very helpful!)

Thanks again,

blessings,

tom

PS what do u guys do/use most often?

Edited March 12, 2008 by Guest
clarity!

[mr_vodka]

Sigh. Of course it can. I dont know what the heck I really have been on lately. I cant keep track of the simplest things. Perhaps I should just stop posting. :

[Fenton]

"Many's the slip 'twixt cup and lip."

[LaRetta]

Don't you dare stop posting. I like your posts!! You usually are VERY accurate when you post - don't let a few days of being a bit mind-scattered stop you. Heck, it's never stopped ME and I've had months at a time like that! ROFLMAO!!

[Lee Smith]

Hey John,

There wouldn't be any of us left on the Forum, if we quit after making an incomplete answer, or erred in what we posted.

Besides, I haven't noticed any one being shy about clarifying, adding to, or pointing out an err if one is made.

If you think your brain is playing games with you now, just wait, it gets better as you age. :yourock:

[mr_vodka]

Thanks guys. Its just that if I didnt something in particular, I would be the first to admit it just like I totally forgot about the option for header and footer in Table View the other day.

But lately, I have been posting some really whacky responses with my head in the clouds I dont know why.

[Thomas Seidler]

Hey now gents,

some way into FMP9 and loving it, particularly the relationships graph for building my db schema!

now i have a many file solution from FMP5, but am seriously thinking of making it a ONE file, many table solution. An influencing factor in this is the ease in creation and use of 'global scripts' - i.e. print scripts - rather than import everytime i update, i can just edit in one place… what are your thoughts…

i put this here cos it again relates to 'global' issue, and couldn't really find a discussion anywhere else on pros/cons of one file/many file structures…

is there a good one I've missed?

Cheers,

tom

[Thomas Seidler]

…and further i have now also found (reading thru the manuals) the wonderful 'set variable' script step which should do what i was after in terms of writeable globals.