Storing options in Registry

Topic

New Reply

I’m an Access developer. A company I do subcontracting work for tends to store a lot of options in the registry, as Access has SaveSetting and GetSetting functions that make this easy. My preference is to store these options in the database itself; perhaps from a pure performance issue this might be slightly slower as it involves updating a database across a network vs. a local registry, but I seem to recall from way-back-when that registry bloating was an issue. My big concern is that they tend to save settings upon exiting a form, whether or not a setting has changed; so there is a lot of registry activity.

Maybe with current versions of Windows this isn’t an issue, but I can’t shake the feeling that all this registry activity is not a good idea. Am I wrong here?

Reply | Quote

Replies

Mark,

I would tend to agree but it depends on a lot of factors:
Are the settings User Specific?
How many settings are there?
How many users are there? {database bloat if settings are per user}
Etc.

Of course this all boils down to being a case by case design decision as I don’t think there is a right or wrong answer since there are so many factors to consider. YMMV!

:cheers:

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

Without regard to the actual database or the software running it…

Settings in the database are specific to that database and everyone accessing it will use the same options. The reverse is the case for an ini file or the registry – options vary by user but apply to all the databases that user accesses.

There are arguments for both and it may be beneficial to have both. But you probably don’t want a situation where functionality changes from user to user.

As far as updating the registry all the time as you describe, I don’t consider that a good idea. A user should have to manually save any changes to settings.

Reply | Quote

You can design a repository of options to be user or database or application or system wide regardless of where they are stored. Whether they should be stored in the registry is not necessarily good or bad these days. Over the past couple of decades Microsoft has made significant changes in how the registry is processed. In modern Windows registry bloat is not the concern it used to be. That said, unnecessary registry updates are just not a good idea. In a modern PC it may not make a noticeable difference but I would only design updates to be made when they are required.

Joe

--Joe

Reply | Quote

It also depends how portable/crash proof you want the settings to be. Registry is potentially not portable and not crash proof.

cheers, Paul

Reply | Quote

Just so we are clear on the situation, most of the settings being saved to the registry are user-specific. When I save them in the database, they are still user-specific. This does have the advantage in that it doesn’t matter where that user logs-in to the database, the settings are always there.

My concern isn’t about performance or “portability”. I was specifically concerned about the advisability of using these frequent updates to the registry. I guess old habits are hard to shake, so I think I’m agreeing with JoeP who said “In modern Windows registry bloat is not the concern it used to be. That said, unnecessary registry updates are just not a good idea.”

Reply | Quote