Persisting public variables

[John F]

Is there a simple way to save the contents of public variables after the
session is over? I can store the information in a table, but was wondering
if there is a more direct way to persist the variables.

Thanks,

John

 

[BruceS]

John,
When the program unloads, the memory that holds the variables is released.
You have to use a table, or a .ini file. I find the former easier.
Bruce

 

[John F]

Bruce,

Thanks for the reply. I will check out the ini file approach but will
probably use a table.

My intent to persisting information is to maintain client-specific
preferences.

Seems one drawback to using a table is if I convert to an Access Project at
some point, this table will have to go on the server shared by all clients
instead of local to a single client. I will have to do some redesign to have
multiple records in the table correspond to different users.

Thanks again,

John

 

[Damian S]

If you think it might head that way in the future, why not plan for that now
while you are implementing it?

Damian.

 

[John F]

Valid point. But that involves designing a log in system or other way to
identify individual clients to point to a specific record in the table. What
is best in that environment is pretty speculative at this point, so not sure
if just a simple approach best for now. Something to think about.

 

[Merle Nicholson]

You can keep client-specific values in local Access tables and migrate common
tables to the server. For settings, I usually set up a 'parms' table with two
columns; key name and value, and then write two small "SaveParm(key, value)",
"GetParm(key, value, default_Value_If_Null)" subroutines to manage them.

 

[John F]

Right now I have all the tables linked and use a different file for the data.
But I thought when converting to an Access Project, that no local data
tables exist any more and that all tables are on the server. Is that not
correct?

 

[Stefan Hoffmann]

hi John,

My intent to persisting information is to maintain client-specific
preferences.
Seems one drawback to using a table is if I convert to an Access Project at
some point, this table will have to go on the server shared by all clients
instead of local to a single client. I will have to do some redesign to have
multiple records in the table correspond to different users.

You can store it in a global table, e.g.

CREATE TABLE dbo.Settings (
ComputerName VARCHAR(64) NOT NULL,
UserName VARCHAR(64) NOT NULL,
ParamName VARCHAR(64) NOT NULL,
ParamValue VARCHAR(64) NOT NULL,
CONSTRAINT PRIMARY KEY (ComputerName, UserName)
)



mfG
--> stefan <--

 

[John F]

Stefan,

Thanks very much.

John

hi John,


You can store it in a global table, e.g.

CREATE TABLE dbo.Settings (
ComputerName VARCHAR(64) NOT NULL,
UserName VARCHAR(64) NOT NULL,
ParamName VARCHAR(64) NOT NULL,
ParamValue VARCHAR(64) NOT NULL,
CONSTRAINT PRIMARY KEY (ComputerName, UserName)
)



mfG
--> stefan <--

 

[Klatuu]

Why has no one suggested creating application level properties?
Look at CreateProperty in VBA Help.

Once a value has been established for an application property, it remaing
presistent until changed via code. It is almost identical to using Public
variables except they don't lose their value when the mdb is closed.