By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,589 Members | 1,194 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,589 IT Pros & Developers. It's quick & easy.

User Settings: table lookup vs keep table open vs load into variables

P: n/a
What do experienced programmers find the most efficient way to handle
user settings.

Currently I have 4 tables which allow various clients to customize my
program to work for them, tblAcademicSettings (fields),
tblBillingsettings (32 fields), tblGraphical (23 fields), tblOwner (33
fields).

There is one record for each table. Admittedly, some of the fields
never change once set up, but many are there to allow the user to make
later changes in how the program works for him.

Til now, I do lookups every time I need info from one of the tables.
Definitely slow, and often causes "Can't open any more databases".
Clearly a better method is needed.

Before I start running benchmarks, I'm hoping folks here can weigh in
on their preferences.

Can I just open all these tables & keep 'em open?
Am I better off setting up public variables and loading the table info
into them all on load of the Switchboard? I will, of course, need to
update the variables any time the forms with this info are changed, but
I'd have to do that with open tables as well.

Or, should I store these values in my own folder in the Registry? Is
this risky?
Or, is there a better way?

Jun 18 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
pe***********@aol.com wrote:
What do experienced programmers find the most efficient way to handle
user settings.

Currently I have 4 tables which allow various clients to customize my
program to work for them, tblAcademicSettings (fields),
tblBillingsettings (32 fields), tblGraphical (23 fields), tblOwner (33
fields).

There is one record for each table. Admittedly, some of the fields
never change once set up, but many are there to allow the user to make
later changes in how the program works for him.

Til now, I do lookups every time I need info from one of the tables.
Definitely slow, and often causes "Can't open any more databases".
Clearly a better method is needed.

Before I start running benchmarks, I'm hoping folks here can weigh in
on their preferences.

Can I just open all these tables & keep 'em open?
Am I better off setting up public variables and loading the table info
into them all on load of the Switchboard? I will, of course, need to
update the variables any time the forms with this info are changed, but
I'd have to do that with open tables as well.

Or, should I store these values in my own folder in the Registry? Is
this risky?
Or, is there a better way?


I always consider what needs to survive an update of the FE application. The settings that
need to be preserved after an update will usually go into an .INI file since I don't like
using registry settings if possible. Registry entries are an alternate and have some pros
and cons (users don't usually accidentally delete them but an .ini file can be but without
a professional uninstall program you could leave those registry entries behind after an
install, i.e. your app doesn't do proper housekeeping, etc).

I recommend reading them in at startup via a class that holds your "global" values. That
class would be updated by your code any time your user changes some type of settings
value. Whether the class reads/writes from a table, the registry or an .ini file is up to you.

There would only be one instance of the class and any updates would change the instance's
properties. Any code that needs to know a user setting queries the instance of the class.

--
'---------------
'John Mishefske
'---------------
Jun 18 '06 #2

P: n/a
All of them of course.
I've got arrays and collections for really speed
critical things, used by functions called from
queries, and lots of functions that will return
the previous value if called with the same parameters.

I've got open recordsets for some big tables that
are less critical and more complex.

I've got DLookups for a few things that are rarely
used.

I've got GetSetting and SaveSetting for things like
MRU list and menu settings.

I don't recommend using a list of unique variables,
it's to easy to loose the values. My arrays and
collections allow me to re-initialise if I have an
error. Other people use objects for the same reason.

(david)

<pe***********@aol.com> wrote in message
news:11*********************@y41g2000cwy.googlegro ups.com...
What do experienced programmers find the most efficient way to handle
user settings.

Currently I have 4 tables which allow various clients to customize my
program to work for them, tblAcademicSettings (fields),
tblBillingsettings (32 fields), tblGraphical (23 fields), tblOwner (33
fields).

There is one record for each table. Admittedly, some of the fields
never change once set up, but many are there to allow the user to make
later changes in how the program works for him.

Til now, I do lookups every time I need info from one of the tables.
Definitely slow, and often causes "Can't open any more databases".
Clearly a better method is needed.

Before I start running benchmarks, I'm hoping folks here can weigh in
on their preferences.

Can I just open all these tables & keep 'em open?
Am I better off setting up public variables and loading the table info
into them all on load of the Switchboard? I will, of course, need to
update the variables any time the forms with this info are changed, but
I'd have to do that with open tables as well.

Or, should I store these values in my own folder in the Registry? Is
this risky?
Or, is there a better way?

Jun 20 '06 #3

P: n/a
Excellent answer.
Jun 20 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.