X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
   Reply to this topicStart new topic
> Ini Files Vs Local Tables, any    
post Oct 30 2017, 11:38 PM

Posts: 93
Joined: 21-January 13


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?

Totally just learning all this stuff... any help is much appreciated.

Go to the top of the page
Jeff B.
post Oct 31 2017, 07:27 AM

UtterAccess VIP
Posts: 10,337
Joined: 30-April 10
From: Pacific NorthWet

JOPO (just one person's opinion)

I tend to go with internal Access tables ... the INI file seems to me to be an extra point of potential failure.
Go to the top of the page
post Oct 31 2017, 07:45 AM

Posts: 653
Joined: 26-May 15
From: The middle of Germany

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.
Go to the top of the page
post Oct 31 2017, 07:46 AM

Posts: 1,820
Joined: 5-February 06
From: Ohio, USA

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'.)

Good luck with your project!
Go to the top of the page
post Oct 31 2017, 08:00 AM

UA Admin
Posts: 36,205
Joined: 20-June 02
From: Newcastle, WA

Acronym of the day! JOPO.

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.
Go to the top of the page
post Oct 31 2017, 10:01 AM

UA Moderator
Posts: 76,906
Joined: 19-June 07
From: SunnySandyEggo

If the concern is losing the user preference due to a corrupted front end application, maybe we can move the local table to the BE and just add an indicator to which user the preference applies.

Just my 2 cents...
Go to the top of the page
post Oct 31 2017, 10:18 AM

Posts: 93
Joined: 21-January 13

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.

Thanks again to everyone for your comments... love this place!
Go to the top of the page
post Oct 31 2017, 10:21 AM

Posts: 93
Joined: 21-January 13

Grover, yes Access... sorry, didn't select that category. Perhaps someone assigned it here? I thought I left it blank as I figured it applied to all versions of Access...

thank you for the reply!
Go to the top of the page
post Oct 31 2017, 10:37 AM

UtterAccess VIP
Posts: 11,300
Joined: 10-February 04
From: South Charleston, WV

Has anybody besides muse43 worked with .ini files?
Go to the top of the page
post Oct 31 2017, 10:49 AM

Posts: 1,820
Joined: 5-February 06
From: Ohio, USA

I think Jack (JLeach) has mentioned them several times...
Go to the top of the page
post Oct 31 2017, 06:36 PM

UtterAccess VIP
Posts: 2,903
Joined: 12-April 07
From: Edmonton, Alberta Canada

I am a BIG fan of using .ini files.

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



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.

Here is parts of a sample setup.ini file:

(believe it or not, the actual ini file is even longer!)

ControlCompanyCode = BG
ControlProv = AB
ControlCity = Edmonton



Sage50DataFile=C:\Users\Public\Documents\Simply Accounting\2015\SAMDATA\Enterprise\Universl.SAI





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.

Albert D. Kallal (Access MVP, 2003-2017)
Edmonton, Alberta Canada
Go to the top of the page
post Oct 31 2017, 07:39 PM

UtterAccess VIP
Posts: 7,014
Joined: 30-June 11

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!
Go to the top of the page

Custom Search

RSSSearch   Top   Lo-Fi    14th December 2019 - 07:50 PM