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:

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 ? :shock: 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:

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:

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 ? :mrgreen:

Du drehst dich imho im Kreis. Der Opaknackpunkt :shock: 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. :cyclops:

[Opa Knack]

:stupid: 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 :-D ) 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

[WoGe]

Hallo

TJVStringGrid hat eine Methode SavetoStream

und hier ist ein Beispiel wie man z.B mit JPGs als Blob abspeichern kann

Ich hoffe das hilft

Gruss
wo

[Hansa]

Mir ist spontan dazu was eingefallen. Wer hat das gesungen ? "Der Antrag zur Erteilung eines Antragsformulars zur Bestätigung der Richtigkeit...." :mrgreen: Es kommt mir nämlich langsam so vor, als ob ein gewaltiger Verwaltungsaufwand betrieben wird, zumindest nicht so wichtige Sachen aus/einzublenden. Für 50 Felder (Daten ?) müssen 300 (Einstellungs ?) Parameter gespeichert werden ? :shock: Ja für wen denn ? Für alle gemeinsam (eventuell eben DB) oder individuell (Ini) ?

Man trennt eigentlich schon immer Daten und Programm. Die Einstellungsgeschichten haben nun aber nichts mit den Produktivdaten zu tun, sondern mit der Art und Weise wie sich das Programm verhält bzw. aussieht. DU versuchst da das Rad schon gewaltig zurückzudrehen.

Wenn Dir der einfachste Weg nicht passt (also INIs), dann verwende wenigstens 2 DBs. Die eine für die Daten und die andere für die Benutzersteuerung. Auch wegen der Backups. Die INIs lassen sich wohl jederzeit wieder aufbauen, selbst wenn sie unrettbar verschwunden sind. Die werden sich aber wohl nicht so oft ändern, wie die "richtigen" Daten. Wenn die nämlich weg sind, dann geht nichts mehr. Egal ob jetzt ein Feld enabled war oder nicht. Was mir immer noch völlig schleierhaft ist : welche Rolle spielt denn das Stringgrid konkret überhaupt ? Werden da richtige Daten eingegeben, oder sollen da die Benutzereinstellungen rein ?

Zitat:

Zitat von Opa Knack

Somit gibt es für die Felder schon einmal drei Parameter...einen für den Typ des Feldes (Combo/Edit)...

Edits (frei) und ComboBoxen (nur Vorgaben) vermischen ? :gruebel: Und das noch irgendwie im Grid und zu guter Letzt in DB speichern ? Ich krieg die Krise. :mrgreen:

[Opa Knack]

Das TJvStringgrid werde ich mir mal anschauen und versuchen, es damit umzusetzen.

@Hansa: Die Felder selbst sind immer Combos, ich stelle sie nur über den Style entweder als Combo oder als Edit (ok, im Endeffekt als Combo ohne Button) dar. Sie werden nicht im Stringgrid angezeigt, sondern in einem eigenen Formular, das Stringgrid ist letztlich nur der Übergang von der Datenquelle dorthin. Bedeutet: Daten werden ins Stringgrid geladen, Routine wertet die Daten aus und verteilt die damit verbundenen Eigenschaften mit den Feldern, die wiederum dynamisch auf einem Formular erzeugt werden. Vom Grid bekommt der Endanwender nichts zu sehen, er braucht bloß auszuwählen, welche Kategorie er verwenden möchte, und erhält im Anschluß das Formular mit den jeweiligen Feldern (und Vorgaben).

Letztlich ist das Stringgrid also eigentlich nur ein Umweg, immerhin könnte ich die Daten ja auch direkt in die Datenbank schreiben bzw. aus ihr lesen. Aber für jemanden, der noch mit Fortran und Cobol gearbeitet hat und der die ersten "richtigen" Programme in Clipper geschrieben hat, ist meine Behelfslösung schon ein großer Schritt :-) Außerdem stünde ich dann auch wieder vor dem Problem, dass ich alle Eigenschaftswerte auslesen und in einem Stream in die Datenbank packen müsste (wenn ich vermeiden will, mindestens mal 50 Felder (wenn ich die Parameter kombiniere) oder eher noch 300 Felder zu definieren).

Inzwischen bin ich aber schon fast so weit, die Daten in ein File zu speichern und dieses File dann in der Datenbank abzulegen :-)

Danke und Gruß
Opa

[Hansa]

Zitat:

Zitat von Opa Knack

Die Felder selbst sind immer Combos, ich stelle sie nur über den Style entweder als Combo oder als Edit (ok, im Endeffekt als Combo ohne Button) dar.

Seit wann kann man eine Combox als Edit einstellen. Oder geht das neuerdings ? :shock:

Zitat:

Zitat von Opa Knack

Vom Grid bekommt der Endanwender nichts zu sehen...Letztlich ist das Stringgrid also eigentlich nur ein Umweg,

Siehe Beitrag #4. Der nächste Umweg : etwas nicht visuelles mit visuellen Komponenten nachzubauen und sie dann unsichtbar zu machen. :zwinker:

Zitat:

Zitat von Opa Knack

..Aber für jemanden, der noch mit Fortran und Cobol gearbeitet hat und der die ersten "richtigen" Programme in Clipper geschrieben hat, ist meine Behelfslösung schon ein großer Schritt :-)

Fange bloß nicht noch damit an, das nachzubauen. Wie wärs, den Quelltext in 8er Schritten zu behandeln und Lochkarten wieder einzuführen ? Kenne selber noch Basic und C. Bleib da bloß weg damit. Zumindest mir. :mrgreen:

[taaktaak]

@Hansa

Zitat:

Wer hat das gesungen ? "Der Antrag zur Erteilung eines Antragsformulars zur Bestätigung der Richtigkeit...."

Reinhard Mey

[Opa Knack]

Eine Combobox kann im Style auf "csSimple" als Edit dargestellt werden (wie gesagt, ist halt eine normale Combobox ohne Button). Hat im Endeffekt für mich den Vorteil, dass alle Eingabefelder Comboboxen sind und ich nicht noch "richtige" Edits einbinden muss (wobei eine Combobox "csSimple" letztlich wie ein Edit gehandelt werden kann).

Entschuldige, wenn meine ursprünglichen Programmierkenntnisse aus einer Zeit stammen, in der man noch nicht in der Lage war, den Großteil von der IDE steuern zu lassen und in der "komplexer und umfangreicher Code" bedeutete, dass man ein paar 5 1/4"-Disketten mehr brauchte. Natürlich ist mir auch klar, dass es moderne Entwicklungsmöglichkeiten gibt, und ich versuche sie auch weitestgehend zu nutzen, aber hin und wieder sind halt noch "veraltete" (dadurch aber nicht unbedingt unnütze) Denkweisen dabei. In zwei Jahrzehnten wirst Du mich vielleicht verstehen :-) Was zählt, ist letztlich nur das Ergebnis, und wenn ich mir anschaue, was mir teilweise an Bananencode (wer's nicht kennt: Software, die beim Anwender reift) unter die Finger kommt, freue ich mich doch, dass ich in meiner aktivsten Lernphase mit den QnD-Methoden absolut untergegangen wäre.

Schon mal vielen Dank an alle, die an meinem Thread mitgearbeitet haben. Ich werde es jetzt mal mit dem TJvStringgrid versuchen, ansonsten fällt mir sicherlich noch der ein oder andere Umweg ein, über den ich mein Ziel erreichen kann (und INI-Dateien werden es sicher nicht sein :-D )

Gruß
Opa