Stringgrid in Datenbank speichern

[Opa Knack]

Hallo,

die Suche nach Stringgrid und Datenbank hat mich leider nicht weitergebracht, also:

Mein aktuelles Projekt enthält benutzerdefinierte Felder, die entweder als Combos oder Edits dargestellt werden. Weiterhin gibt es zusätzliche Parameter (z. B. ob das jeweilige Feld aktiviert wird oder welche Caption das dazugehörige Label bekommen soll). Um mir's einfach zu machen, habe ich die jeweiligen Parameter in einem Stringgrid festgehalten, das dann je nach Bedarf angepasst wird und dessen Daten dann ausgelesen bzw. auf die jeweiligen Felder verteilt werden. Dieses Stringgrid möchte ich nun in einer Datenbank speichern. Klar könnte ich die Daten direkt mit Feldern in der Datenbank verbinden, was aber meines Erachtens nach nicht ergonomisch wäre.

Meine Frage lautet nun, ob schon mal jemand etwas vergleichbares gemacht hat und mit welchem Code ich das hinbekomme. Ich habe schon ein wenig herumgesurft und dabei bei den Schweizern (warum ist da eigentlich nichts mehr los?) etwas gefunden, womit ich die Inhalte des Grids in einem File ablegen kann, ich schaffe es aber nicht, das soweit umzubasteln, dass ich es umleiten kann.

Danke vorab
Opa

[Hansa]

Zitat von Opa Knack:

...Ich habe schon ein wenig herumgesurft und dabei bei den Schweizern (warum ist da eigentlich nichts mehr los?) etwas gefunden, womit ich die Inhalte des Grids in einem File ablegen kann, ich schaffe es aber nicht, das soweit umzubasteln, dass ich es umleiten kann.

Was soll woin umgeleitet werden ? Wieso File ? Was hat Stringgrid mit DB zu tun ? Fragen über Fragen. Für mich schreit das da ziemlich nach INI-Datei.

Delphi-Quellcode:

      Ini := TIniFile.Create(DateiName);
      Ini.WriteInteger(Name,'Caption',Caption);

Name steht im Bsp. für die Form, das könnte aber auch ein TEdit oder sonstwas sein. Wenn dann noch User angelegt sind und homepath zur Speicherung dieser Datei verwendet wird, dann kann im Prinzip jeder Benutzer seine eigenen Einstellungen beeinflussen und steht am nächsten Tag wieder genau da, wo er vorher auch war. Ansonsten heißt es : Felder in DB anlegen, eventuell die User anlegen und das auch noch richtig speichern. IMHO zu aufwändig, ohne irgendeinen Vorteil zu bringen.

[omata]

Was spricht gegen ein DBGrid?

[Hansa]

Was denn noch ? Zunächst wäre mal statt Grids etc. TStrings/TStringlist in betracht zu ziehen.

[worker]

Generell spricht nichts gegen das Speichern von Konfigurationsinformationen in einer Datenbank.
Ich kenne Dein Projekt nicht, unterstelle aber mal frech, dass das dafür etwas zu oversized ist

Daher stimme ich Hansa zu, und rate Dir erstmal zu Ini-Dateien.

Solltest Du dennoch den Weg mit der DB gehen, so legst Du Dir eine entsprechende Struktur in Deiner Tabelle an, also die Felder so, wie die Spalten des Stringgrids angeordnet sind, und schreibst dann die Daten Zeile für Zeile (StingGrid.Rows) aus Deinem Grid in die Tabelle; am Besten mit einer Query-Komponente und einem INSERT-Statement.

Zitat von omata:

Was spricht gegen ein DBGrid?

Auch dafür müssen die Daten erstmal in eine DB

[sx2008]

Mach dir doch eine Tabelle folgender Struktur:

Code:

Key|Value

Datentyp Key:varchar(50), Value:varchar(250)

Dann eine Procedure zum Speichern:

Delphi-Quellcode:

procedure Txxx.SaveKeyValue(const key,value:string);
begin
  Query.Parameter.ParamValues['Key'] := key;
  Query.Open;
  if Query.IsEmpty then
  begin
    Query.Append;  // neuen Datensatz anlegen
    Query['Key'] := key;
  end
  else
    Query.Edit;
  Query['Value'] := value;
  Query.Post;
  Query.close;
end;

procedure Txxx.SaveStringGridCell(Row,Col:Integer; const value:sring);
begin
  SaveKeyValue(Format('SG_%d:%d', [Row, Col]), value);
end;

Hinweis: der Sourcecode ist möglicherweise nicht fehlerfrei, weil ich den "frei von der Leber weg" eingetippt habe.
Aber das Prinzip ist, dass du die x- und y-Koordinaten (also Col und Row) in einen "Key" umwandelst und alles in einer Tabelle speicherst.

Ein Grund, Konfigurationsdaten in der Datenbank und nicht in einer INI-Datei zu speichern, wäre die Mehrplatzfähigkeit.
Jeder Arbeitsplatz kann über die Datenbank auf die gleiche Konfigurationdaten zugreifen.
Bei INI-Dateien bräuchte man zusätzlich zum Datenbankserver auch noch einen Fileserver.
Es hängt aber immer vom Ziel ab.
Manchmal möchte man jeden Arbeitsplatz für sich konfigurieren; dann könnte eine INI-Datei günstiger sein.

[Opa Knack]

Hallo,

das Projekt stellt im Endeffekt eine Akquisedatenbank dar, die momentan knapp 5000 Einträge mit Zusatzinformationen wie Emails oder ähnlichem beinhaltet. Da die Akquise in verschiedene Richtungen geht, müssen Kategorien für ein wenig Übersicht sorgen. Innerhalb dieser Kategorien gibt es dann zum einen Standardfelder, zum anderen aber auch benutzerdefinierbare Eingabemöglichkeiten (so dass zum Beispiel in der einen Kategorie die Felder "Erstkontakt" und "Quelle" bereitgestellt werden, in der anderen dafür "Kunde seit" und "Letzter Kontakt").

Da ich sowieso schon mit einer Datenbank arbeiten muss, um die Daten festzuhalten, würde es in meinen Augen eher Sinn machen, auch die Kategorien in ihr abzulegen. Jetzt ist aber der Punkt, dass pro Kategorie knapp 50 Felder bereitgestellt werden (nein, das ist nicht überdimensioniert ), wobei jedem Feld Attribute wie "enabled" sowie der Typ des Eingabefeldes (wird dann dynamisch erzeugt) und etwaige Vorgabewerte zugeordnet werden. Neben ein paar anderen Parametern kommen dann noch die Standardwerte für Combos dazu (so dass zum Beispiel die Combobox "Land" alle Länder beinhaltet). Da es beim gegenwärtigen Äquivalent bereits 7 Kategorien gibt und es weitere Planungen gibt, diese noch weiter zu spezialisieren, scheint die Datenbank auch sinnvoll. Weiterhin ist es meines Erachtens einfacher, ein einzelnes Datenbankfile zu handeln und bei Backups zu berücksichtigen als zusätzlich zum File auch noch x Ini-Dateien. Inis wären sicherlich für ein kleineres Vorhaben geeignet, habe ich bislang auch das Meiste mit gelöst, nur in diesem Fall fürchte ich, dass sie nicht ausreichen.

Sicherlich wäre es einfacher, einfach entsprechende Felder in einer Tabelle anzulegen und diese zu füllen, dadurch ergibt sich dann aber wieder das Problem, dass diese dann auch jedesmal jedes für sich gehandelt werden müssen, was das Ganze wieder ein wenig fehleranfälliger macht (mal eben 50 Einträge auslesen, dazu dann die Parameter (pro Feld wären dies aktuell 6 zusätzliche Einträge), das macht dann insgesamt 350 Einträge, die gehandhabt werden müssten). Also war meine Überlegung, dass es sinnvoller wäre, die Felder sowie alle notwendigen Daten in einem Stringgrid abzubilden, das dann ausgelesen werden kann und "in einem Rutsch" gehandelt werden kann (z. B. als Stream in ein Blob gespeichert bzw. geladen werden kann). Alternative Ideen sind natürlich immer herzlich willkommen

@Hansa: Das File ist nicht erwünscht. Ich habe nur ein paar Zeilen Code gefunden, mit denen ich ein Stringgrid in ein File speichern kann. Diese Zeilen wollte ich soweit umschreiben, dass sie nicht mehr auf ein File sondern auf die Datenbank weisen. Ist mir aber bislang nicht gelungen.

Hat jemand eine Idee?

Danke und Gruß
Opa

[Hansa]

Zitat von Opa Knack:

...
@Hansa: Das File ist nicht erwünscht. Ich habe nur ein paar Zeilen Code gefunden, mit denen ich ein Stringgrid in ein File speichern kann. Diese Zeilen wollte ich soweit umschreiben, dass sie nicht mehr auf ein File sondern auf die Datenbank weisen. Ist mir aber bislang nicht gelungen.

Das Datenbankfile auch nicht ?

Du drehst dich imho im Kreis. Der Opaknackpunkt ist das bereits gesagte. Ehrlich gesagt : die Logik des Vorhabens ist mir zu hoch. Mein Vorschlag zielt darauf ab, die getätigten Änderungen der Forms in INIs zu speichern und die Windows-Benutzersteuerung auszunutzen, um eventuell individuelle Einstellungen zu speichern/zu laden. Oder eben ein Verzeichnis für alle Benutzer eines Rechners.

sx2008 hat ja schon gesagt, dass im Mehrplatzbetrieb eventuell ein noch zentraleres Vorgehen nötig werden könnte. Nur, es sollen eventuell 50 Felder auf disabled gesetzt werden ? Von wem und wo wird das gemacht ? Da fängts nun wieder von vorne an : wenn an einer Stelle alle Felder disabled werden sollen, wozu sind sie denn dann überhaupt da ? Dann kann ja kein Benutzer was dran ändern. Ergo : auch mit DB ist Benutzersteuerung nötig. Und ein DB-Admin, der jeden Mist umstellen muss. Geht irgendwer aber hin und ändert etwas zentral in der DB auf enabled, dann kann jeder drauf zugreifen. Wie gesagt : mir zu hoch.

[Opa Knack]

Ich versuche mal, mein Vorhaben in logische Schritte zu gliedern:

In einer (mehr oder weniger) Adressverwaltung haben die Nutzer die Möglichkeit, bis zu 50 Felder für Eingaben zu nutzen. Wenn es einem User reicht, nur 2 Felder z. B. für Vor- und Nachnamen zu nutzen, dann sind es 2 Felder und die restlichen 48 sind nicht enabled, wenn aber noch weitere Informationen benötigt werden (z. B. für die Adresse, den Ansprechpartner bei einem Unternehmen oder ähnliches), dann können es bis zu 50 Felder sein.

Jedes Feld kann entweder als Combo oder als Edit angezeigt werden. Möchte der User z. B. ein Feld für den Nachnamen nutzen, dann wird er es wahrscheinlich als Edit anzeigen lassen, möchte er es hingegen für das Land nutzen, dann kann er es als Combo anzeigen lassen und Länder als Items hinterlegen, damit diese nicht jedesmal wieder auf's Neue eingegeben werden müssen.

Somit gibt es für die Felder schon einmal drei Parameter: Einen für den Status (enabled true/false), einen für den Typ des Feldes (Combo/Edit) und einen für hinterlegte Items.

Darüber hinaus kann pro Feld auch ein Standardtext vorgegeben werden (also z. B. ein vorgegebener Ort im dazugehörigen Feld oder ähnliches). Dies wäre der vierte Parameter.

Alle Felder sind mit Labels versehen, die dann natürlich anzeigen sollen, was im jeweiligen Feld angegeben werden soll. Die Captions dieser Labels stellen den fünften Parameter dar.

Ein weiterer Parameter wird intern verwendet, aber ist ja jetzt auch nicht sooo wichtig.

Ich habe also pro Feld 6 Parameter, bei 50 Feldern macht das 300 Angaben, die jeweils variieren können.

Darüber hinaus bietet das Programm die Möglichkeit, die "Feldergruppen" in eigenständigen Kategorien abzuspeichern. Wenn ich also z. B. die Kategorie "Nur Name" aufrufe, würden also nur Vor- und Nachname aktiviert, der Rest bleibt deaktiviert. Wenn ich hingegen "Kundenansprachen" aufrufe, werden die dafür relevanten Felder wie "Firma", "Ansprechpartner", "Erstkontakt", ... aktiviert. Diese Kategorien sind unabhängig voneinander und ermöglichen eine flexiblere Handhabung des Programms.

Die Feldparameter werden, um es ein wenig einfacher zu handhaben, in einem Stringgrid abgelegt, das dann je nach Kategorie neu befüllt wird und aus dem die relevanten Informationen für die Felder gezogen werden. Rufe ich also die Kategorie "Nur Name" auf, lädt das Programm die dazu gehörigen Informationen in das Grid, geht sie durch und verteilt sie anschließend auf die jeweiligen Felder. Rufe ich die Kategorie "Kundenansprachen" auf, wird das Stringgrid gelöscht, die Informationen zu dieser Kategorie werden eingelesen und das Ganze fängt wieder von vorne an.

Um das in einer INI-Lösung auszudrücken, würde das bedeuten, dass ich einfach jedem INI-File einen Namen gebe und mit den Daten aus diesem File alle Felder "befülle". Wäre sicherlich machbar, würde in meinen Augen aber folgende Nachteile bedeuten:

• es sind zusätzliche Dateien zu berücksichtigen, wenn es Backups zu machen gilt
• wahrscheinlich müsste ich auf BigINI oder ähnliches schwenken, da die Daten mitunter doch recht umfangreich sein können (so zum Beispiel wenn ich alle Länder in einer Combo vorgeben will)
• ich würde zusätzlich zur Datenbank, in der die Eingaben in den Feldern verwaltet werden, noch eine zusätzliche Speichermöglichkeit nutzen, was mir persönlich unlogisch erscheint
• wenn längere Informationen vorgegeben werden sollen (zusätzlich gibt es noch ein Memo für Bemerkungen), muss ich mich nicht darum kümmern, diese im Ini-File entsprechend unterzubringen

Insofern scheint es mir sinnvoller, die Daten aus dem Stringgrid in einer Tabelle in der Datenbank abzulegen. Es gibt also eine Tabelle, z. B. "Kategorien", in der die einzelnen Datensätze für jede Kategorie enthalten sind, in denen wiederum neben dem Titel der Kategorie auch der Inhalt des jeweiligen Stringgrids (wahrscheinlich dann wohl in einem Blob) enthalten ist. Zusätzlich gibt es noch eine Tabelle, in der alle Eingaben, die in den Feldern gemacht wurden, gehandhabt werden (ansonsten würde es ja keinen Sinn machen ) sowie weitere Tabellen, da dieses Projekt nur ein Teil eines etwas größeren Vorhabens ist.

Meiner Meinung nach ist das wesentlich performanter, vor allem habe ich den Vorteil, schnell mal ein Backup (halt nur für das Datenbankfile und nicht noch zusätzlich für die ganzen Ini-Dateien) machen zu können und nutze dabei die Gegebenheiten (Datenbank), die ich sowieso für den Rest des Ganzen (sprich die Eingaben) benötige.

Wenn jemand eine Idee hätte, wie ich das Ganze einfacher und trotzdem mit den gleichen Inhalten bewerkstelligen kann, bin ich natürlich für Tipps dankbar. Ich denke aber mal, dass es sich dabei dann wahrscheinlich nicht um INIs handeln würde.

Insofern brauche ich dringend einen Tipp, wie ich das Stringgrid in die Datenbank bringe (wie geschrieben z. B. als Stream in ein Blobfeld), ohne dabei in der Datenbanktabelle erst einmal 300 Felder definieren zu müssen (was das Ganze dann wieder ziemlich aufwändig machen würde).

Danke und Gruß
Opa

[Opa Knack]

Kleiner Nachtrag noch:

Sicherlich wäre es auch möglich, das Stringgrid zuerst in eine temporäre Datei zu speichern und diese dann wiederum in ein Blob-Feld in der Datenbank abzulegen. Aber das dürfte doppel gemoppelt sein, oder? Theoretisch sollte es doch auch ohne den Umweg gehen.

Danke und Gruß
Opa