I gave up on INI files primarily due to security settings that prevented
writing to them. Now I store all system-wide settings in a very simple
DBISAM configuration file:
ConfigFile Columns:
 Key: String - forced to uppercase
 StringValue
 IntegerValue
 BLOBValue

I access each type with a simple call to a method of my Configuration
datamadule:
i := GetIntegerSetting('USERCOUNT');
MailServerName := GetStringSetting('MAILSERVER');

But instead of making the GetSettingX calls visible outside the
configuration data module object, I created properties to add compile time
checking to insure I'm not trying to access an invalid key name. So now I
have calls like:

MailServerName := ConfigModule.MailServerName; <-property of data module
with read/write access as needed

Works great and is easily extensible to add new settings/properties. I love
having the compile-time checking that using properties gives me. I also
REALLY like that I can hack settings in that will never change by using
DBSYS, even for remote connections across the internet. Cool stuff with that
DBISAM C/S.

For local machine or user settings such as grid layouts (DevEx) I always use
the current user branch of the registry. I keep a list of my keys used and
if I stop using any, I am sure to delete them in a cleanup routine as part
of my setup program. I hate stray registry keys.

No problems so far.

-Johnnie

If you use DevExpress grids, take a look at TcxPropertiesStore. It looks
like a handy way to store component properties (not just DevEx components)
to INI, Registry, or BLOB field using streams.

-Johnnie

Johnnie

>MailServerName := ConfigModule.MailServerName; <-property of data module
>with read/write access as needed

I did that for a while as well, but got fed up of writing the get/set functions so now I

GetCfgInt(cfg_MaxBytesPerEMail,1024);

The declared variable (cfg_MaxBytesPerEMail = 'MaxBytesPerEMail') also stops me miss-typing

Roy Lambert

Adam H. wrote:
....
> In the past, I used to store my users settings in the registry. I
> have now changed to storing them in ini files in the same directory
> as the executable.

I also use a INI file - but only for the parameters needed to connect the
database. The rest is in a INI-alike table, with a class to access the
records. Works since years.

Ralf

"Adam H." <ahairsub4@rREMOVEMEspamSTOPPER.jvxp.com> wrote in message
news:9DA0A477-8B6F-4C37-9A07-0BB3AE7E7CEE@news.elevatesoft.com...
>
> I have had it pointed out to me that this is not ideal for server based
> terminal sessions (such as Windows Terminal Services or Citrix sessions),
> and that I should change my application so all settings are stored in the
> database (and not on either ini's or the registry). - I guess I would have
> to have *some* settings still outside, else the application would not know
> where to look for the data.
>

For general C/S apps I would use:
For per user settings - I store them in the registry - HKLU.
System wide settings - minimal - (pre-database connection) in a .INI.
System wide settings (post-database connection) in a config type table.

For a middle tier:
I would most likely use an .INI.

We run off profiles in the local LAN and off Citrix for remote users - never
had a problem with any of the above.

D.

Adam:
Check the following
http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=33699&page=1#msg33699

This issue has been discussed several times before.  I have not changed my mind
since my comments in April 2003 -
The approach I suggested continues to work for our applications running under
Win9x, Win2K, WinXP, Win2003 Server and under Terminal Services.

Applications running under Terminal Services presents its own set of issues.
These also have been discussed before.
Check the following
http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=50208&page=1#msg50208



--
.... Norm

Norman W. Clark, Clark-Tech Inc.
nclark@clark-tech.com
www.clark-tech.com
www.smbproducts.com


"Adam H." <ahairsub4@rREMOVEMEspamSTOPPER.jvxp.com> wrote in message
news:9DA0A477-8B6F-4C37-9A07-0BB3AE7E7CEE@news.elevatesoft.com...
> Hi,
>
> I've just been challenged by an administrator of the computer systems of one
> of my clients to change the way I develop my applications, which I thought I'd
> run by this community to get some thoughts on.  
>
<snip>

Thanks to all those that took the time to reply, and post links to other
conversations regarding this issue!

At present, in my own situation, I have decided that the best move would be
to store on the server, within a table solely set aside for properties, and
to have one ini file in the executable directory to point to the data
location.

I haven't decided whether I will switch to the TcxProperties component, or
whether I will continue to use the jvFormStorage, and use their DBStorage
component. I think the JVFormStorage component would be a better option at
present, as I can point all these on all the different forms to one
TJVAppDBStorage component, and save/restore in one go, instead of requiring
a seperate load/save for each TcxProperties component.

By doing this, I don't have to worry about either file permissions, or
upsetting Network Admins by putting extra stuff in their registry.

Thanks once again for all your advice!

Cheers

Adam.

Hi

I took Normans advise while working on our last application - it's working
fine

All Application wide general settiings stored in an INI file in the
application folder
All user settings, grids user preserences etc stored in an INI file in the
user profile.  I use Dev Express grids and Raize ini component as well as
Storage lib as mentioned earlier in the thread and these can be tweaked to
allow storage in both places

Regards

Bobby

"Norman W. Clark [Clark-Tech Inc.]" <nclark@clark-tech.com> wrote in message
news:79DCA449-4AB8-4010-81F5-0221B29201DF@news.elevatesoft.com...
> Adam:
> Check the following
> http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=33699&page=1#msg33699
>
> This issue has been discussed several times before.  I have not changed my
> mind since my comments in April 2003 -
> The approach I suggested continues to work for our applications running
> under Win9x, Win2K, WinXP, Win2003 Server and under Terminal Services.
>
> Applications running under Terminal Services presents its own set of
> issues. These also have been discussed before.
> Check the following
> http://www.elevatesoft.com/scripts/newsgrp.dll?action=openmsg&group=5&msg=50208&page=1#msg50208
>
>
>
> --
> ... Norm
>
> Norman W. Clark, Clark-Tech Inc.
> nclark@clark-tech.com
> www.clark-tech.com
> www.smbproducts.com
>
>
> "Adam H." <ahairsub4@rREMOVEMEspamSTOPPER.jvxp.com> wrote in message
> news:9DA0A477-8B6F-4C37-9A07-0BB3AE7E7CEE@news.elevatesoft.com...
>> Hi,
>>
>> I've just been challenged by an administrator of the computer systems of
>> one of my clients to change the way I develop my applications, which I
>> thought I'd run by this community to get some thoughts on.  
>>
> <snip>
>