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]

[Sir Rufo]

Generell würde ich ab einer bestimmten Ebene nicht mehr mit 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 TIniFile , oder ...) spielt dann keine Rolle mehr, Hauptsache die Implementierung liefert das Gewünschte.

[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);

[baumina]

Zitat von 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);

Danke, dafür werde ich mich entscheiden.

Danke auch allen anderen für die nützlichen Hinweise.

[baumina]

Ich bin Urlaubsreif, ich merks, mir rennt zu dem die Zeit weg BIS zu meinem Urlaub, also beanspruche ich nochmals euch, sry.

baumina und Pointer ... da treffen schon immer zwei Welten aufeinander.

Meine Funktion in der DLL, die mit dem Hauptprogramm kommuniziert sieht so aus :

Delphi-Quellcode:

type
  TDBComProc = function( aTable, aCommand, aParam : pAnsiChar):integer of object;

var
  DBCommunicator : TDBComProc;

function DBCom(aTable, aCommand, aParam : Ansistring):Ansistring;
var
  pTable, pCommand : array[0..100] of Ansichar;
  pParam : array[0..200] of Ansichar;

begin
  result := '';
  if @DBCommunicator = nil then
  begin
    Exit;
  end;
  strPCopy(pTable,aTable);
  strPCopy(pCommand,aCommand);
  strPCopy(pParam,aParam);
  DBCommunicator(pTable,pCommand,pParam);
  result := StrPas(pParam);
end;

Die Array-Größe von 0..200 reicht mir für die Ini-Datei nun nicht mehr. Was muss ich denn da ändern, dass ich da keine festen Größen mehr haben muss?

[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

Erst wenn du 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.

[DeddyH]

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

[samso]

Zitat von Der schöne Günther:

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 von samso:

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.