You could make a table for this -type- of thing, and use different columns
or different rows to handle the different cases. Actually, though, I think
I would go for the table. If you have one setting you want to save today,
you may have more later, and it will be convenient if you have a table with
columns with the same names/types as you want to store.
Another option is to use the XML library to create and manage a settings
document in the same directory as the MDB. The advantage of this is that,
if you deploy a new copy of the database front-end, you don't erase the
user's preferences - they're still in the xml file.
On 21 Oct 2003 23:47:58 -0700,
so*********@hotmail.com (John) wrote:
I have a form that prints a report for a weekly staff meeting. On the
form is an unbound field to enter the staff meeting date, which is
subsequently used as a parameter in the report's query data source.
I'd like to have this date stored/recalled so that when the user opens
the form to print the report for the staff meeting each week, the form
"recalls" the previously entered date. That way the user doesn't have
to look at the calendar or guess.
Will I need to create a table just to store this date, or is there a
better way?