Ini-Datei in DB-Feld verlegen

[baumina]

Hintergrund: Im Moment habe ich mehrere DLLs, die eigene INI-Dateien haben, in denen verschiedene Einstellmöglichkeiten drin stehen (für jede DLL steht da was anderes drin). Diese INI-Dateien müssen in die DB verlagert werden, damit ich von überall Zugriff drauf habe.

Meine Idee: Ich mache ein neues DB-MemoFeld in dem dann der Inhalt der bisherigen Ini-Datei drin steht.

Mein Problem dabei: Um weiterhin die Funktionen aus TIniFiles wie ReadString, ReadSection, etc. verwenden zu können, hätte ich das gerne genommen, jedoch will TIniFiles einen Dateinamen beim Create, den ich ja dann nimmer hätte.

Meine Fragen: Kann ich TIniFiles o.ä. auch ohne Datei verwenden?
Steh ich grad aufm Schlauch oder macht das so gar keinen Sinn?
Soll ich lieber eine andere Richtung gehen?

[DeddyH]

Ohne es ausprobiert zu haben: TMemIniFile verwenden, ohne Dateinamen erzeugen und mit SetStrings befüllen, die dort anzugebende TStrings-Instanz kann man ja im Vorfeld aus dem BLOB laden.

[edit] Falls keine Sections benötigt werden, ginge es mit den Key/Value-Methoden von TStrings sogar noch einfacher. [/edit]

[Der schöne Günther]

Mit "ohne Dateinamen erzeugen" ist wohl "Mit Nonsens-Dateinamen (wie leeren String) erzeugen" gemeint. Denn der Konstruktor will auf jeden Fall einen :wink:

Erst wenn du

Delphi-Quellcode:

myMemFile.UpdateFile()

aufrufen würdest, käme es zu Problemen.


PS: Ich habe mich auch ganz von der "normalen" TIniFile verabschiedet, den diese baut noch auf irgendwelche 16-Bit Windows-Funktionen auf die gerne mal fehlschlagen. Mit TMemIniFile ist mein Leben ein besseres geworden.

[Jumpy]

Du könntest ja auch eine eingene Klasse schreiben, "TDBIni" oder so, die nach aussen hin genau die selben Möglichkeiten bietet, wie TIniFiles, sprich ReadString, WriteString usw. Jenachdem was du so brauchst kannst du ja auch Dinge die du nicht brauchst weglassen (RedSections oder so) wobei das in sofern schlecht ist, das man von einer Klasse mit INI im Namen so Funktionen erwarten würde (bei späterer Wiederverwendung).
Intern aber wandelt die Klasse das in DB-Abfragen usw. um, d.h. natürlich auch, dass du dafür in der DB eine passende Tabelle brauchst.

[DeddyH]

Natürlich meinte ich einen Leerstring, man kann ja keine Parameter weglassen ;)

[Sir Rufo]

Generell würde ich ab einer bestimmten Ebene nicht mehr mit

Delphi-Quellcode:

TIniFile

u.ä. arbeiten, sondern mir immer eine abstrakte Klasse oder Interface bauen, die für den Zugriff auf wie auch immer geartete Informationen/Resourcen verantwortlich ist.

Wie das dann implementiert ist (mit

Delphi-Quellcode:

TIniFile

, oder ...) spielt dann keine Rolle mehr, Hauptsache die Implementierung liefert das Gewünschte.

[mkinzler]

Dann würde ich die Ini-Dateien aber nicht in einem (B)LOB ablegen, sondern die Struktur direkt in der DB Abbilden.

[bcvs]

Ich habe genau so einen Fall und mache es so: (s. DeddyH)

Delphi-Quellcode:

  IniFile:=TMemIniFile.Create('');
  Data:=TStringList.create;
  Data.Text:=TableIni.FieldByName('Data').AsString;
  IniFile.SetStrings(Data);

[samso]

Zitat:

Zitat von Der schöne Günther (Beitrag 1267116)

denn diese bauen noch auf irgendwelche 16-Bit Windows-Funktionen auf

Ist das ein Gerücht, oder kannst Du das belegen?

[Der schöne Günther]

Zitat:

Zitat von samso (Beitrag 1267124)

Ist das ein Gerücht, oder kannst Du das belegen?

Beispiel:

Delphi-Quellcode:

{*******************************************************}
{                                                       }
{           CodeGear Delphi Runtime Library             }
{                                                       }
{ Copyright(c) 1995-2013 Embarcadero Technologies, Inc. }
{                                                       }
{*******************************************************}

unit System.IniFiles;

[...]

procedure TIniFile.WriteString(const Section, Ident, Value: string);
begin
  if not WritePrivateProfileString(MarshaledString(Section), MarshaledString(Ident),
                                   MarshaledString(Value), MarshaledString(FFileName)) then
    raise EIniFileException.CreateResFmt(@SIniFileWriteError, [FileName]);
end;

MSDN:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Zitat:

WritePrivateProfileString function

Copies a string into the specified section of an initialization file.

Note This function is provided only for compatibility with 16-bit versions of Windows. Applications should store initialization information in the registry.

Das hat mich mal einiges an Zeit gekostet da die Unit-Initialisierungs/Finalisierungsblöcke einen Einfluss auf diese Methode haben. Auf einem WinXP-System wurde bei Anwendungsende (Klassendestruktor, der kommt nach der Unit-Finalisierung) die Ini-Datei nie auf die Platte geflushed, auf Win7 aber schon.