Thanks Allen a touch more than I need since this is a single location
application. I will however look at your approach and do appreciate it.

Allen Browne wrote:
Joe, you've already got some good answers. Here's a couple more ideas.

Application and User settings
=====================
A disadvantage of creating a Field in a miscellaneous table for each
default is that as the application grows you have to modify the table
every time you want to add a new default. While that's doable, it's
messy when you have multiple users at different locations. It might
be better to create a more generic table with fields such as these:
TheVariable Text The name, such as "SalesTaxRate".
TheUser Text Zero-length string if it applies to all
users.
TheValue Text The current value to use for this
variable DataType Long A value that is a member of
vbVarType Descrip Text Description of what this
variable is used for.

Advantages:
- Add new variables without redesigning the table.
- Store application-level preferences.
- Store user user-level preferences (e.g. suppress this warning for
this user), adding new users whenever needed.
- Have the user's preferences available from any machine they log
into, and keep them when the front end is updated (because they are
not kept in the workstation's front end.)

Disadvantages:
All values are stored as text. Use VarType(), IsNumeric(), and
IsDate() to validate that the entry is suitable, but it still
requires a bit of manipulating. For example, percentages need to be
stored as fractions, e.g. 0.1 for 10%, and dates need to be converted to
double so the regional
settings of one user are not interpreted differently by another.

Suggestions:
- Use a 2-field primary key: TheVariable + TheUser.
- Set these properties for the TheUser field:
AllowZeroLength Yes
Default Value: ""
As part of the primary key, neither field can be null, but TheUser
defaults to a zero-length string which represents an application-wide
preference.
Object-level settings
===============
Sometimes you want the software to remember a setting per object,
such as which one of a workstation's printers should be used as the
default for printing a label report. You might want to consider
creating a custom property on the report itself.

Advantage: The property stays with the report even if it is copied or
renamed.

Disadvantage: the setting is lost when yor replace the front end with
an update.

You can download an example of this approach for Access 2002 or 2003:
Printer Selection Utility
at:
http://allenbrowne.com/AppPrintMgt.html

HTH.


"Joe Cilinceon" wrote in message
...
What is the best way to have defaults in one location but available
to the whole application. Some examples would be Sales Tax rate,
Late Fee charge in addition to things like scanners/printers or
other things used with in the program.

--

Joe Cilinceon