I'm working on an older Access database (built in mid 90's and is now being used on 2003) that uses an INI file to store user info. I'm pretty new and wouldn't have thought to use this approach (actually, just learned what an INI file is...). I would have gone with a local table and just stored any parameter info in there...

I'm wondering what the advantages of using an INI file are and whether I should consider using this approach in my own databases... is it just an older thing?

IMO it depends on the data stored in the INI file. If the local database gets corrupted or needs to be updated you can just replace it with a fresh copy of the same or newer version. With local tables you would loose the user info. With an ini file the user info is preserved.

I'll venture my JOPO as well... after a little 'googling' on the subject.

It's a matter of opinion, comfort, ease... basically one of those situations where there's nothing wrong with one way or another, it's a 'style'. There are several ways to do it, so whatever you're comfortable with. If you need to change it to something you're more comfortable with, then by all means.

My style... a 'local database' containing all the 'local tables', for things like user information to common tables (things like 'tblPositions' that is a list of personnel positions in the company that is only going to change when a new position is created, which is not often, and I do update the table every log into the database 'system'.)

This is posted in the Visual Basic 2003 forum, so first, let's confirm that you're actually not talking about "Visual Basic" in general, but about "Access" in particular.

So, assuming that to be the case, I see pros and cons to both styles.

With an ini, you have to track and maintain two separate files, the accdb and the ini that goes with it. With an accdb, you risk losing the local user preferences in an internal table to corruption. Which is the greater risk exposure? I can't really say. It may just come down to what you prefer.

Wow, really insightful and helpful replies guys, thanks! Wanted to make sure I wasn't missing out on anything great about INI that I couldn't do with local tables. Got a very clear idea now... sounds like local tables is a perfectly viable solution. I like the idea of storing it in the backend (where there are backups).

By the way, one more potential downside to INI files (that was the reason for my client coming to me) was that the database was set up to create the INI file in the C:\ directory. However, once the user updated to I believe Windows 8, you need top level Admin rights to write to that location. So even though there were no error messages coming up, the INI file was no longer being created for quite some time, leading to a whole host of issues that although problematic, were not obviously related at first... of course, this kind of thing is also avoided using local tables.

If you're curious, for now I decided to grab the location of the Access file and use that as the new INI save location.

There is a set of “api” that you can use to read + manage + set values from a ini file.

The main advantages are:

You can add, edit, create new "sections" in the ini file - and you can do so without having to worry about some table in the application. And the ini is "better" at separating out parts (and thus not needing several tables inside of access).

Things like user settings, version number, country codes etc. exist outside of the application. This means that you can edit the .ini without having to launch Access. And this also means your installing code can modify/update or use the information outside of the application.

So critical was my installer - it also can use parts of the .ini file.

I in fact have two .ini files

Setup.ini

Version.ini

The version.ini of course has version number, and ALSO the path name to the install location. So on startup, I can read version number, and then read install location. That install location (useally a server folder) also has a version.ini file, and also a setup.exe. So on startup if a new version is aviablity, then it like 3 lines of VBA code to shell out to the new setup.exe, and exit the access application (and by exiting, then the front end can be easy updated).

Same goes for setup.ini. I find it easier to modify, add new values and new features without having to change the table design.

So city location, country, path to temp working files, and setup for things like say a QuickBooks interface I find better to be outside of the setup

For example, I have the ability to use remotedesktop, and launch the "remote" users edition of outlook, NOT the local copy. If I roll out a new front end, then the users settings are lost.

So major settings, and major parts of my applications use ini files. There is good reason they been around since windows 3.1, and STILL remain a popular choice today.

So having settings separate from the application is likely the best case. And thus you can modify the settings, and as noted my installer code often makes updates to the above ini files - something very difficult to do with an installer and a table inside of Access.

And as noted, I can roll out new front ends to workstations, but not worry about user settings being overwritten.

You also forgot a third approach, using the registry to store application and user settings.

Each has its use and which you use can come down to personal preference.

Ini files are very easy to work with and even the user can do so with a simple text editor. This can be a pro and a con depending.

A local table can be very useful, but what happens when you update/replace the FE? You need to plan for that, copy everything first...

Another alternative is to have a standard linked user settings table this way the settings are always preserved whether you update/replace the FE or whether the user accesses the db from another PC...

Yet another alternative is to use a hybrid approach, have a Local Table that copies the setting once at the startup from a linked table. This can be useful on slow connections, otherwise no real advantage.

Also note that the local table, ini file and Registry approach have the advantage of being accessible even if the BE ins't!