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.

[Bernhard Geyer]

Zitat:

Zitat von samso (Beitrag 1267124)

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?

Das Konzept der Ini-Dateien ist aus der "guten alten" 16-Bit Zeit.
MS schreibt auch das man das nur noch wegen einfacher Portierung von 16-Bit Code auch unter 32-Bit zur verfügung hat (http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx).

Lustig ist hier das man dir Registry empfiehlt ob diese ja auch schon wieder "böse" ist. Heutzutage würde man xml-"ini"-Dateien verwenden.

[Perlsau]

Zitat:

Zitat von baumina (Beitrag 1267113)

Diese INI-Dateien müssen in die DB verlagert werden, damit ich von überall Zugriff drauf habe.

Ich würde hier gleich Nägel mit Köpfen machen und jeder DLL eine eigene Tabelle spendieren, die alle Einstellungen aufnimmt. Ähnlich verfahre ich in allen meinen Database-Applications: Einstellungen werden in Tabellen gespeichert, der Index ist die Benutzer-ID. Damit die Tabellen nicht zu umfangreich werden, verwende ich mehrere Einstellungstabellen:

• Tabelle Benutzer für Benutzername, Passworthash, Formularpositionen und -größen, Farbeinstellungen und Sonstiges;
• Tabelle BTab für Sortier- und Tabelleneinstellungen;
• und je nach Bedarf noch diese und jene Tabelle.

Die Benutzertabelle enthält einen PK mit automatisch erzeugten IDs. Die anderen Benutzer-Tabellen verwenden die jeweilige ID ebenfalls als PK. Auf diese Weise kann bei Muli-User-Anwendungen jeder Benutzer seine individuellen Einstellungen speichern.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1267127)

Lustig ist hier das man dir Registry empfiehlt ob diese ja auch schon wieder "böse" ist. Heutzutage würde man xml-"ini"-Dateien verwenden.

Oder gleich ein TClientDataSet verwenden, falls man keine Datenbank-Anwendung baut.

[mkinzler]

Eine Tabelle pro Dll ist nicht notwendig. Flexibler ist es diese als Schlüssel oder noch besser in eine eigene Tabelle zu verwalten.

[Sir Rufo]

Es ist doch völlig Wurscht, ob jede DLL eine eigene Tabelle hat, oder ob es eine Gesamt-Tabelle gibt. Der DLL/Anwendung muss das egal sein. Die Implementierung der Zugriffsklasse/Interface muss das wissen und sonst keiner.

Ab dann habe ich alle Freiheiten der Welt und kann auch zum Testen einfach mal eine Dummy-Implementierung drunter hauen, oder eben eine Tabelle ansprechen, oder eben eine für jede DLL, oder für DLL x eine Datei, DLL y die Registry, für die Anwendung ein Zugriff auf alles zusammen ...

[mkinzler]

Die Erweiterung, um eine Dll ist dann aber einfacher. Zudem entspricht das eher (meinem) Verständnis von Normalisierung.

[baumina]

Zitat:

Zitat von bcvs (Beitrag 1267121)

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?

[DeddyH]

Wieso machst Du es nicht wie MS und spendierst der Funktion einen Var-Parameter vom Typ integer? Der wird beim Aufruf mit der Größe des reservierten Puffers belegt und wenn zu klein, gibt die DLL die benötigte Größe in eben diesem Parameter zurück? Dann kannst Du den Speicher dynamisch anfordern und bist an keine fixe Größe gebunden.

[baumina]

d.h. ich brauche nochmal eine Funktion in der dll, die mein Hauptprogramm erst mal nach der zu erwartenden Größe fragt?


EDIT : Ach ne ... oh man, ich muss nachdenken, schaffs aber grad nicht.

[DeddyH]

Nicht unbedingt eine neue Funktion, aber neue Parameter.

[Sir Rufo]

Zitat:

Zitat von baumina (Beitrag 1267159)

d.h. ich brauche nochmal eine Funktion in der dll, die mein Hauptprogramm erst mal nach der zu erwartenden Größe fragt?

Jein, das kann man auch mit einer Funktion machen, die als Rückgabewert die Größe rausgibt, die man dann natürlich auswertet, die Größe anpasst und die Funktion nochmal aufruft.

Oder man erfragt (bekommt) statt der Csllback-Funktion ein Interface und arbeitet mit diesem Interface in der DLL.

Zitat:

Zitat von DeddyH (Beitrag 1267160)

Nicht unbedingt eine neue Funktion, aber neue Parameter.

Der Rückgabewert reicht doch, wenn man den auch auswerten würde ;)

[baumina]

Mein Problem ist, dass ich nicht alle DLLs gleichzeitig umstellen mag, das sind mir zu viele, zudem einige noch Delphi 2007 sind und noch nicht mit Delphi XE getestet wurden. Deswegen wollt ich vermeiden, dass ich in meinem Hauptprogramm an der Stelle was ändere.

Ich denke das hat so auf die Schnelle alles keinen Zweck (ich hab nur noch 6 Stunden Arbeitszeit), in meinem Hirn dreht sich alles, da kann nur Mist dabei rauskommen.

Schieb ich mal auf nach meinen Urlaub, dann hab ich auch wieder mehr Nerv.

EDIT: @Sir Rufo Mir scheint ich sollte mich mal mit Interfaces beschäftigen, da du so begeistert nahezu alles damit löst.

[DeddyH]

@Sir Rufo: sie hat nunmal mehrere Strings, aber nur einen Rückgabewert. Da sollte dieser IMO lieber einen ErrorCode zurückgaben statt einer Längenangabe.

[Jumpy]

Zitat:

Zitat von baumina (Beitrag 1267165)

Ich denke das hat so auf die Schnelle alles keinen Zweck (ich hab nur noch 6 Stunden Arbeitszeit), in meinem Hirn dreht sich alles, da kann nur Mist dabei rauskommen.

Gibt's bei euch etwa kein Kompilierverbot vor Urlaubsantritt :-D

[baumina]

Zitat:

Zitat von DeddyH (Beitrag 1267168)

@Sir Rufo: sie hat nunmal mehrere Strings, aber nur einen Rückgabewert. Da sollte dieser IMO lieber einen ErrorCode zurückgaben statt einer Längenangabe.

Ja, der Rückgabewert ist ein ErrorCode, der wird nur aus ... frag mich nicht nach Gründen ... hier nicht ausgewertet.

[baumina]

Zitat:

Zitat von Jumpy (Beitrag 1267170)

Gibt's bei euch etwa kein Kompilierverbot vor Urlaubsantritt :-D

Ich bin Alleinkompilierer, aber mir gefällt die Idee, ich sollte es mir selbst auferlegen.

[DeddyH]

Ohne Gewähr schnell heruntergetippelt:

Delphi-Quellcode:

library BufferDLL;

{ Wichtiger Hinweis zur DLL-Speicherverwaltung: ShareMem muss die erste
  Unit in der USES-Klausel Ihrer Bibliothek UND in der USES-Klausel Ihres Projekts
  (wählen Sie 'Projekt-Quelltext anzeigen') sein, wenn Ihre DLL Prozeduren oder Funktionen
  exportiert, die Strings als Parameter oder Funktionsergebnisse übergeben. Dies
  gilt für alle Strings, die an oder von Ihrer DLL übergeben werden, auch für solche,
  die in Records und Klassen verschachtelt sind. ShareMem ist die Interface-Unit zur
  gemeinsamen BORLNDMM.DLL-Speicherverwaltung, die zusammen mit Ihrer DLL
  weitergegeben werden muss. Übergeben Sie String-Informationen mit PChar- oder ShortString-Parametern, um die Verwendung von BORLNDMM.DLL zu vermeiden.
 }

uses
  Windows,
  SysUtils;

{$R *.res}

function SomeTest(Param1: PAnsiChar; var Param1Len: integer; Param2: PAnsiChar;
  var Param2Len: integer): integer; stdcall;
const
  Result1 = 'Hallo Welt';
  Result2 = 'Wuppdi';
begin
  Result := 0;
  if Param1Len < Length(Result1) then
    begin
      Param1Len := Length(Result1);
      Result := ERROR_INSUFFICIENT_BUFFER;
    end;
  if Param2Len < Length(Result2) then
    begin
      Param2Len := Length(Result2);
      Result := ERROR_INSUFFICIENT_BUFFER;
    end;
  if Result = 0 then
    begin
      StrPCopy(Param1, Result1);
      StrPCopy(Param2, Result2);
    end;
end;

exports
  SomeTest;

begin

end.

Und der Aufruf:

Delphi-Quellcode:

function SomeTest(Param1: PAnsiChar; var Param1Len: integer; Param2: PAnsiChar;
  var Param2Len: integer): integer; stdcall; external 'BufferDLL.dll';

procedure TFormTest.ButtonTestClick(Sender: TObject);
var
  s1, s2: Ansistring;
  Len1, Len2: integer;
begin
  Len1 := 0;
  Len2 := 0;
  s1 := '';
  s2 := '';
  if SomeTest(nil, Len1, nil, Len2) = ERROR_INSUFFICIENT_BUFFER then
    begin
      SetLength(s1, Len1);
      SetLength(s2, Len2);
      if SomeTest(PAnsiChar(s1), Len1, PAnsiChar(s2), Len2) = 0 then
        ShowMessage(Format('%s%s%s', [s1, sLineBreak, s2]));
    end;
end;

[baumina]

Hm, in einem Rutsch geht das dann ja wohl auch nicht oder? Du rufst ja SomeTest zweimal auf.

[DeddyH]

Ja natürlich, erst ermittle ich die benötigten Stringlängen und dann erst die Strings. Das ist aber nicht unüblich.

[baumina]

Wenn ich mein Array nun einfach auf 10000 mache, was mir sicher gut reichen wird, schreien dann alle mit "Oh Gott, oh Gott, bist du wahnsinnig ...." auf?

[DeddyH]

Geht auch, aber dann musst Du ggf. den zurückgegebenen String wieder kürzen. Es bleibt Dir überlassen, was Du machst.

[p80286]

Zitat:

Zitat von baumina (Beitrag 1267179)

Hm, in einem Rutsch geht das dann ja wohl auch nicht oder? Du rufst ja SomeTest zweimal auf.

Geht ganz gut kostet aber u.U. massig Zeit. Z.B. bei der Abfrage der vergebenen Dateiberechtigungen hab ich eine Buffergröße vorgegeben, die für den größten Teil der Abfragen passt. "Nachteil" ist dann natürlich daß Du den normalen Weg (Buffer ist groß genug) und die Ausnahme (Buffer ist zu klein) berücksichtigen mußt. Und natürlich wie bereits erwähnt, die Länge passt nicht automatisch.

Gruß
K-H