I'm pondering using a table to store settings for an app, and wonder if
anyone has done any sort of "TIniFile" lookalike already to do this sort
of thing. I'm expecting to just have columns for "itemname", "intvalue"
and "stringblob", and then it would be usable instead of TIniFile.

My aim with this is to use the DBISAM backup system to create me a single
file storage. At the moment I zip everything as I need the database and an
INI file. All thoughts appreciated.

/Matthew Jones/

"Matthew Jones" <matthew@matthewdelme-jones.delme.com> wrote in message
news:memo.20060105173242.4356H@nothanks.nothanks.co.uk...
> I'm pondering using a table to store settings for an app, and wonder if
> anyone has done any sort of "TIniFile" lookalike already to do this sort
> of thing. I'm expecting to just have columns for "itemname", "intvalue"
> and "stringblob", and then it would be usable instead of TIniFile.
>
> My aim with this is to use the DBISAM backup system to create me a single
> file storage. At the moment I zip everything as I need the database and an
> INI file. All thoughts appreciated.
>

I just did the same thing, but very simplified. I created a table with
string, blob, and memo fields and a single "Setting" field (string) as the
primary key. I put the table, a create query and a session component on a
TData module class.

I added a few private methods like:
   procedure WriteSetting(Setting: String25; Value:String);
   function GetSetting(Setting: String25): String; overload;
   function GetSetting(Setting: String25; Default:String): String;
overload;

But I don't use any of these directly, instead I added properties to read or
write each setting. That way the compiler helps when I need to use them
throughout my code. I haven't moved my BLOB stuff over yet, but it will be
used to hold customer logos and some RTF files.

No more INI files for me.

I was also ambitious and did the same thing to my application event logging.
I used to write logging to a text file. I only wish I didn't do both at the
same time I converted the BDS2006.

-Johnnie

Matthew Jones wrote:
> I'm pondering using a table to store settings for an app, and wonder
> if anyone has done any sort of "TIniFile" lookalike already to do
> this sort of thing. I'm expecting to just have columns for
> "itemname", "intvalue" and "stringblob", and then it would be usable
> instead of TIniFile.

I use that all the time. The real INI file contains only the settings to
find the database (path, server name etc). I'll upload my unit to .binaries.

Ralf

Thanks both - will respond properly when I get back on Tuesday.

/Matthew Jones/

I was thinking that a direct "ReadString" etc "TIniFile" compatible
function set would be ideal, then I could just pass in the module without
changing any other code. But maybe better to have a change anyway...

> But I don't use any of these directly, instead I added properties to
> read or write each setting.

This is the most interesting one to think about. When I've worked on code
with app specific properties in settings, they always seem to add
complexity and reluctance to changes later. What I really like about the
INI file (and registry) is you can just read it any time for any old
setting, and not go to a lot of trouble. This makes it ideal for the odd
debug or "just in case" parameter. But with OOP it may be possible to
derive a class and do it nicely, so the base class does the database stuff
and the derived does the app specific interface.

Hmm. Encouraging that it works in principle!

/Matthew Jones/

> I'll upload my unit to .binaries.

I'll work out how to fetch it, and study it shortly. Many thanks.

/Matthew Jones/