UtterAccess.com
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    
 
   
muse43
post Oct 30 2017, 11:38 PM
Post#1



Posts: 30
Joined: 21-January 13



Hi,

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.


Thanks!
Go to the top of the page
 
Jeff B.
post Oct 31 2017, 07:27 AM
Post#2


UtterAccess VIP
Posts: 9,859
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.

--------------------
Regards

Jeff Boyce
Microsoft Access MVP (2002-2015)

Mention of hardware or software is, in no way, an endorsement thereof. The FTC of the USA made this disclaimer necessary/possible.
Go to the top of the page
 
PhilS
post Oct 31 2017, 07:45 AM
Post#3



Posts: 397
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.

--------------------
An excursion to the raw COM API with VBA: How to hide the Taskbar Button of a window.
Go to the top of the page
 
nuclear_nick
post Oct 31 2017, 07:46 AM
Post#4



Posts: 1,376
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!

--------------------
"Nuclear" Nick
____________
The top three reasons to hide code; 1) It's not your own. 2) It's your own, but it's so crappy you don't want anyone to see it. 3) The comments in your code would get you in a lot of trouble if ever made public.
Go to the top of the page
 
GroverParkGeorge
post Oct 31 2017, 08:00 AM
Post#5


UA Admin
Posts: 30,971
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
 
theDBguy
post Oct 31 2017, 10:01 AM
Post#6


Access Wiki and Forums Moderator
Posts: 71,014
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...

--------------------
Just my 2 cents... "And if I claim to be a wise man, it surely means that I don't know" - Kansas
Microsoft Access MVP | Access Website | Access Blog | Email
Go to the top of the page
 
muse43
post Oct 31 2017, 10:18 AM
Post#7



Posts: 30
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
 
muse43
post Oct 31 2017, 10:21 AM
Post#8



Posts: 30
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!
This post has been edited by muse43: Oct 31 2017, 10:22 AM
Go to the top of the page
 
projecttoday
post Oct 31 2017, 10:37 AM
Post#9


UtterAccess VIP
Posts: 8,604
Joined: 10-February 04
From: South Charleston, WV


Has anybody besides muse43 worked with .ini files?

--------------------
Robert Crouser

My company's website
Go to the top of the page
 
nuclear_nick
post Oct 31 2017, 10:49 AM
Post#10



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


I think Jack (JLeach) has mentioned them several times...

--------------------
"Nuclear" Nick
____________
The top three reasons to hide code; 1) It's not your own. 2) It's your own, but it's so crappy you don't want anyone to see it. 3) The comments in your code would get you in a lot of trouble if ever made public.
Go to the top of the page
 
AlbertKallal
post Oct 31 2017, 06:36 PM
Post#11


UtterAccess VIP
Posts: 2,540
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

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.

Here is parts of a sample setup.ini file:

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

CODE
[CONTROL]
ControlCompanyCode = BG
ControlEstimateFolder=\\srv-edm\AxisMIS\Estimate
ControlInvoiceFolder=c:\ControlMISdev\Invoice
ControlEstimateAttachmentFolder=c:\ControlMISDev\Estimate\Files
ControlDocketAttachmentFolder=c:\ControlMISDev\AxisMISFiles\Docket\Files
ControlProofFolder=c:\ControlMISDev\proof
ControlLocalProgramFolder=
ControlServerUseWindowsAuthentication=0
ControlServer=ALBERTKALLAL-PC\SQLEXPRESS
ControlDatabase=AxisMIS
ControlUser=AxisMIS
ControlPassword=
ControlCountry=USA
ControlProv = AB
ControlCity = Edmonton
ControlRemoteOutlook=0

[PDQ]
PDQEnabled=0
PDQDatabase=C:\PDQ\Office\PDQ\pdq_save.mdb
PDQQuoteXMLFolder=c:\PDQ\Office\PDQ\Quotes
PDQSetupDatabase=c:\PDQ\Office\PDQ\pdq_Burke_eco2.mdb

[KSTATION]
KStationEnabled=0
KStationServer=PC-EDM\KOMORI_SQLSERVER
KStationDatabase=KOMORI
KStationUser=KOMORI
KStationPassword=

[SAGE50]
Sage50Enabled=-1
Sage50Folder=
Sage50ExportFolder=
Sage50DataFile=C:\Users\Public\Documents\Simply Accounting\2015\SAMDATA\Enterprise\Universl.SAI
Sage50User=MIS
Sage50Password=

[QUICKBOOKS]
QuickBooksEnabled=0
QuickBooksProgramFolder=
QuickBooksExportFolder=

[SMARTSTREAM]
SmartStreamEnabled=0
SmartStreamServer=SS_DIRECTOR\IWDBSQL
SmartStreamDatabase=iWayDbSql
SmartStreamUser=SSAxis
SmartStreamPassword=SSAxis
SmartStreamJobFolder=\\SS_DIRECTOR\NewEdition\IPanel\JobTemplates

[PITSTOPSERVER]
PitStopServerEnabled=0
PitStopServerProgramFolder=
PitStopServerInputFolder=
PitStopServerOutputFolder=

[UPLOADPORTAL]
UploadPortalEnabled=0
UploadPortalSite=http://111.111.111.111/Upload


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
kallal@msn.com

Go to the top of the page
 
DanielPineault
post Oct 31 2017, 07:39 PM
Post#12


UtterAccess VIP
Posts: 5,364
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!

--------------------
Daniel Pineault (2010-2017 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    19th November 2017 - 11:02 PM