Ini-Datei in DB-Feld verlegen

[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.