We help IT Professionals succeed at work.

Any workaround for 64kb limit for INI files ?

deep_haze
deep_haze asked
on
Medium Priority
347 Views
Last Modified: 2013-12-28
I use a private INI file in C:\Windows to store info about the state of my application & use calls like WriteProfileInt(...),GetProfileInt(...).
But I have observed that calls to WriteProfileInt fail after the initialisation file reaches about 64 kb.
To cite an example, suppose the application uses an INI file to store information about users ( I know INI files are not intended for such purposes, but can one use them if one really wants to?? ).
Further say addition of info about each user adds 8kb to the ini file. So the application would have an inherent limitation of not being able to store info of more than 8 users(8*8=64kb).
Does this mean that I cannot use an INI file after it reaches 64 kb size?
Comment
Watch Question

Commented:
The only way I have managed to do it in the past is to have subInifiles - the main ini file holds a reference to a second ini file that holds the actual data.

I posted the following answer in response to a similar question last year:

*************************************
There is no fix unfortunately - ini files are a hangover from Windows 3.x - new programs are supposed
to use the registry to hold settings etc.  I still uses ini files to hold shared settings for multiuser
applications - by far the easiest way to do it.

I have a set of standard templates in Word 97 that are used by a large Government department - the ini
file holds all addresses etc and recently went over the 64k when several new departments were added.
 As a short term fix I stripped out all comments and white space which eventually dropped me about 350
bytes below the limit.

I eventually rewrote the application to use a series of ini files - I had a line in the main ini file
that held the name of the subsiduary ini file

eg something like this:

Maininifile:

[Setup]
Department=Dept2A

[DepartmentSubIni]
Dept1=SubIni1.ini
Dept2=Subini2.ini
Dept2A=Subini2.ini
Dept3=SubIni3.ini

SubIni2.ini
[Location]
Address=1 The High Street, London
Phone=0171 555 5555

Then in the main prog, i did something like this:  (ini handling wrapped in functions)

Department=getfromini(sMainInifile,"Setup","Department","")

DeptSubIni=getfromini(sMainInifile,"DepartmentSubIni",Department, "")

sAddress=getfromini(deptsubini,"Location","Address","")

***********************************************

In your case, have a separate ini file for each user, then store a pointer in the main ini file.  Retrieve the subinifile name from the main ini, then the user details from the relevant subinifile

eg.  
MainIni-------

[Users]
JOHN123=JOHN123.INI
PAUL999=PAUL999.ini
;---------------------

PAUL999.INI-----

[Details]
Surname=Smith
Forename=Paul
StaffID=999
;--------------------

Commented:
cguinn is right--INI files are limited to 64K. However, this is a limitation of the Windows functions to read and write these files--if you write your own functions to do this job you don't have to bother with the 64K limit!

However, it would probably be safer to again follow cguinn's advice and to use a separate file for each user--this way you don't lose your entire user database if one file gets corrupted!

Author

Commented:
thanx cquinn, your comment was as close to an answer as possible :-)
are you aware of any other alternatives apart from the registry (pretty time consuming biz). for instance what advantages/disadvantages wud one have if one used normal files( C style files) or a database for that matter.

Regards,
Deep.

Commented:
For anything more than small amounts of config data, I would personally store it in a database.  I am a VB/Access programmer, so would probably keep it an an Access database of some sort, with the records keyed on User name.

I had to use the workaround on ini files on a project I inherited that used the ini files to prefill various parts of Word templates for a large Government department here in the UK.  The templates had been rolled out to dozens of servers, for thousands of users, and I was not given the time to redevelop what I believed would have been a much more robust solution - I was told to apply bandages so it could limp along to the end of the contract.

If it is a multi-user system running over a network, I think the registry is probably not the place to store it - It is local to the machine, not shared.

With text files, you would have to write your own handling routines.  This could be time consuming.

Thanks for the points,

Chris

Author

Commented:
Thanks for the help Chris.

Deep.

Explore More ContentExplore courses, solutions, and other research materials related to this topic.