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.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"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.