I need to send users to layouts based on both native currency and page size used in their local. Currently there is no individually assigned user accounts, just account names for job function and local.

I am planning to use a pattern count from the privilege set to capture information. EG: _UK and _EU for currency, and _PSA and _PSL (Page Size L for Letter, et all US sizes).

All my scripts, including navigation and print are in my User Interface. (I capture the OS to deal with Win/Mac page setup, and set UI system formats as well).

Data is in several other files which are not accessed by users directly.

So my main Q: Is there any reason to add these suffixes to the privs in the data files?

Three User Interface accounts have separate Priv Sets of finance_US_PSL, finance_UK_PSA, and finance_EU_PSA. On the data file can all three accounts have only one Priv Set of Finance, as the only relevant function left there is allowing access to finance table and fields?

And has anyone worked out a simpler method for such matters?

[color:gray]Will I kick myself when it turns out FM10 has solved this by capturing more info from the OS? (Like I could get the client to upgrade 100 seats just for that)

No need to add the suffix in the data files.

Do you have a globals table in your UI file? You could set the privilege info into a global field so that your data files could use it when needed.

Meaning each user goes to the "globals" screen in the UI and sets up their prefs? (and I check at login to see that the required fields are not empty, and if so, lead the "new" user there.)

I like it! Thanks!

You could do that, but that's not what I meant. My point is that it makes scripting more convenient if you grab certain info when the user logs in, such as user ID, privileges etc.

Now, you could use global variables for this, but that won't help you if you need to access the variable from another file. A globals table can be a good solution since all you need is a file reference; global fields do not require a relationship to read/write.

There's nothing wrong with setting up a user prefs table, since you bring it up, and in fact you may want to use it in conjunction with a globals table for the reasons I just outlined.

[color:gray]"grab certain info when the user logs in, such as user ID, privileges"

That won't work for this situation. But I like the global fields in a UI table. I've gotten so used to variables I forgot what these little babies can do (Doi!). I'm already using globals to filter things from an "access" table, so what's a few more. It should be easy enough to switch from checking the priv. set to checking the global for currency or print preferences.