How to save variable values for future use?

[deko]

I have a number of variables that need to be saved for later use. For
example, the path to be used for exporting files, options for creating
reports, interface preferences, saved search parameters, etc...

The obvious solution is to store this stuff in a table -- all I need is one
row in a very wide table.

I have more than one form in which these parameter variables are set. I set
the forms to "AllowAdditions = False" so the table stays at one row.

Are there other ways to accomplish this? What I'm doing seems like a
hack.... and I'm encountering problems when there is no data in the form --
it comes up blank because of the "AllowAdditions = False" setting.

Thanks in advance!

[Larry Linson]

Perhaps you could code _something_ as a default value for each of the
fields? That is, if the user has not modified it, use the directory in
which the database resides as the path for exporting; interface color
defaults to use Windows colors (which is not a bad idea, as users will be
used to that color scheme), etc. Then you won't have the case of the record
being all empty or non-existent.

Larry Linson
Microsoft Access MVP
"deko" <dj****@hotmail.com> wrote in message
news:H0*******************@newssvr25.news.prodigy. com...

I have a number of variables that need to be saved for later use. For
example, the path to be used for exporting files, options for creating
reports, interface preferences, saved search parameters, etc...

The obvious solution is to store this stuff in a table -- all I need is one row in a very wide table.

I have more than one form in which these parameter variables are set. I set the forms to "AllowAdditions = False" so the table stays at one row.

Are there other ways to accomplish this? What I'm doing seems like a
hack.... and I'm encountering problems when there is no data in the form -- it comes up blank because of the "AllowAdditions = False" setting.

Thanks in advance!

[Tom Mitchell]

An alternate solution is a table with two fields:

tblVariable

VariableName PK
VariableValue

Set up a Get procedure to pass in the VariableName and send out the
VariableValue and a Let procedure to change them. You'll need to trap
nulls somewhere (either in the Get procedure or in the calling
procedure) to determine what to do if the VariableName has not yet
been initialized.

This a lot more flexible than your approach because it allows you to
add & delete variables without involving design changes.

There are other solutions involving saving to the registry, but that
never made much sense to me when a table would work just as well.

HTH

Tom

"deko" <dj****@hotmail.com> wrote in message news:<H0*******************@newssvr25.news.prodigy .com>... I have a number of variables that need to be saved for later use. For
example, the path to be used for exporting files, options for creating
reports, interface preferences, saved search parameters, etc...

The obvious solution is to store this stuff in a table -- all I need is one
row in a very wide table.

I have more than one form in which these parameter variables are set. I set
the forms to "AllowAdditions = False" so the table stays at one row.

Are there other ways to accomplish this? What I'm doing seems like a
hack.... and I'm encountering problems when there is no data in the form --
it comes up blank because of the "AllowAdditions = False" setting.

Thanks in advance!

[deko]

hmmmm.... that might work....

It's interesting that you mention the Windows Registry. From what I
understand, that's what the Registry is all about -- a database of settings
for the computer. My guess is that if I re-write my application in C#, I'll
be using the Registry to solve these kind of problems.
"Tom Mitchell" <rt*****@swbell.net> wrote in message
news:70**************************@posting.google.c om...

An alternate solution is a table with two fields:

tblVariable

VariableName PK
VariableValue
Set up a Get procedure to pass in the VariableName and send out the
VariableValue and a Let procedure to change them. You'll need to trap
nulls somewhere (either in the Get procedure or in the calling
procedure) to determine what to do if the VariableName has not yet
been initialized.

This a lot more flexible than your approach because it allows you to
add & delete variables without involving design changes.

There are other solutions involving saving to the registry, but that
never made much sense to me when a table would work just as well.

HTH

Tom

"deko" <dj****@hotmail.com> wrote in message

news:<H0*******************@newssvr25.news.prodigy .com>... I have a number of variables that need to be saved for later use. For
example, the path to be used for exporting files, options for creating
reports, interface preferences, saved search parameters, etc...

The obvious solution is to store this stuff in a table -- all I need is one row in a very wide table.

I have more than one form in which these parameter variables are set. I set the forms to "AllowAdditions = False" so the table stays at one row.

Are there other ways to accomplish this? What I'm doing seems like a
hack.... and I'm encountering problems when there is no data in the form -- it comes up blank because of the "AllowAdditions = False" setting.

Thanks in advance!

[Arno R]

Deko,
I think using a table is a better choice than using the registry.
Think of the occasion when someone restores the registry ... all your settings are gone?
When you use a table all your settings are IN the database. I guess you will have more control then.

It's interesting that you mention the Windows Registry. From what I
understand, that's what the Registry is all about -- a database of settings
for the computer. My guess is that if I re-write my application in C#, I'll
be using the Registry to solve these kind of problems.

I use a (local, because some settings may vary from one user to another) table
with only two fields and generic procedures called GetSetting(setting) and WriteSetting(setting).
In the past I used a one record-tabel with multiple fields, but I needed to update the tabledef to
often.

--
Hope this helps
Arno R

[rkc]

"deko" <dj****@hotmail.com> wrote in message
news:Fu*******************@newssvr25.news.prodigy. com...

hmmmm.... that might work....

It's interesting that you mention the Windows Registry. From what I
understand, that's what the Registry is all about -- a database of settings for the computer. My guess is that if I re-write my application in C#, I'll be using the Registry to solve these kind of problems.

What difference does a programming language make?
Will you be re-writing your application without a database?
If I had a mind to store settings somewhere other than in the database
the application uses, an .ini file or some kind of xml format would
be a choice before the registry.