Stringgrid aus Datenbank füllen

[Luckner]

Hallo,
habe eine Tabellen mit mit Datensätzen wie z.Bsp.: Text(String), Zeile(Integer), Spalte(Integer). In Zeile und Spalte befindet sich die Zahlen aus derer Kombination die Zellen-Nummer zusammensetzt. In meiner Form habe ich ein StringGrid mit 10 Zeile und 7 Spalten. Jetzt würde ich den Text in der richtigen Zelle schreiben. Jetzt könnte ich mit sql.select für jede Zelle den richtigen Text herausfinde, aber es würde bedeuten dass ich 70 Sql.select-Abfragen hintereinander machen muss. Geht es möglicherweise intelligenter?

Danke, Luckner

[bcvs]

Machs doch anders herum:

Du machst ein Select. Dann gehst du die Query durch mit

Delphi-Quellcode:

While not Query.eof

und schreibst den Text in die so erhaltenen StringGrid-Zellen.

[rapante]

Hy,
kannst du es nicht andersherum angehen? Also erst alle Daten holen und dann die Ergebnismenge durchgehen und die Zellen füllen...

Delphi-Quellcode:

Query.SQL.Text := 'SELECT * FROM table';
Query.open;
while not Query.Eof do
begin
  FillCell(query.fieldbyname('zeile').asinteger, query.fieldbyname('spalte').asinteger, query.fieldbyname('text').asstring);
  query.next;
end;

[DeddyH]

Entweder habe ich es falsch verstanden, oder Du hast eine sehr eigenartige Tabelle, wenn darin Darstellungsinformationen wie Zeile und Spalte stehen. Ich würde einfach eine Abfrage starten, die Spaltenanzahl der Grid anhand der zurückgegebenen Feldanzahl und die Zeilenanzahl anhand der Anzahl der Datensätze festlegen. Dann einfach datensatzweise durchgehen und die Spalten aus den Feldern des aktuellen Datensatzes befüllen.

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1280230)

Entweder habe ich es falsch verstanden

Möglich, denn seine Tabelle enthält pro Datensatz einen Zellenwert und die Information, in welcher Zeile und Spalte der Wert im Grid zu stehen hat.

[p80286]

Code:

select zeile,spalte,text from tabelle
order by zeile,spalte

Und das dann in das Stringgrid einfügen.
(ich hoffe da gibt es keine Lücken, sonst müßte man jeden Datensatz an seine Position bringen)

Gruß
K-H

[himitsu]

Oder man lässt sich via SQL die Daten in einer Tabelle zusammenetzen (joinen) und bindet das Ganze ganz einfach nur noch an ein DBGrid. :angel:

* Sequenz generieren erste bis letzte Zeile <- min(zeile) bis max(zeile)
* geht die Sequenz durch <- SELECT spalte_x.text, ... FROM sequenz
* und joint für die einzelnen Spalten dann jeweils noch entsprechenden Wert dort rein <- LEFT JOIN tabelle AS spalte_x ON zeile = sequenz AND spalte = x
* kann man sich z.B. bei den vielen Codes für Pivottabellen abgucken

[Luckner]

Hätte ich doch etwas ausführlicher erklären sollen. Also es geht um eine ToDo-Darstellung für eine Woche. Die Spalten sin die Tage der Woche und die Zeilen jeweils eine Stunde. Jetzt werden die Datensätze nicht hintereinander in der Tabelle eingetragen, sondern so wie es kommt. Also als Beispiel: der 1-ter Termin der eingetragen wird mit der ID=1 ist z.Bsp. Dienstag 15:00Uhr. Also Stringgrid.cells[8,2] (8. Zeile, 2. Spalte). Neuer Eintrag in die Datenbank ID=2 Montag 09:00Uhr Stringgrid.cells[2,1], usw. Manche Zellen sind auch leer. Der Anwender geht in die entsprechende Zelle und schreibt seinen Text da rein. Beim Speichern, schreibe ich in die Datenbank den Text und die Zellen-Koordinaten. Das funktioniert auch gut. Jetzt nur vernünftig auslesen und zuordnen.

[Uwe Raabe]

Zitat:

Zitat von Luckner (Beitrag 1280245)

Die Spalten sin die Tage der Woche und die Zeilen jeweils eine Stunde. Jetzt werden die Datensätze nicht hintereinander in der Tabelle eingetragen, sondern so wie es kommt. Also als Beispiel: der 1-ter Termin der eingetragen wird mit der ID=1 ist z.Bsp. Dienstag 15:00Uhr. Also Stringgrid.cells[8,2] (8. Zeile, 2. Spalte). Neuer Eintrag in die Datenbank ID=2 Montag 09:00Uhr Stringgrid.cells[2,1], usw. Manche Zellen sind auch leer.

Das Vorgehen bleibt dasselbe: Iteriere durch die Datenbanktabelle und ordne jeden Datensatz der passenden Zelle im Grid zu. Das wurde doch bereits ziemlich zu Anfang so beschrieben.

[Sir Rufo]

Rein grundsätzlich betrachtet bietet es sich immer an, sowas nicht direkt von der Datenbank in ein Control zu pusten. Das verführt dann auch sehr leicht dazu in der Datenbank seltsame Strukturen zu erstellen (das passt besser zum Control) oder sich sonstwie zu stark an der Präsentation zu orientieren.

Von der Datenschicht holt man sich einfach eine Liste mit den Daten ab

Delphi-Quellcode:

TList<TTermin>

. Diese Liste wird dann in eine Klasse gedrückt aus der man wiederum die mundgerechten Informationen bekommt, um die Daten in einem StringGrid anzuzeigen (oder einer ListView, ListBox, ComboBox, ...).

[Dejan Vu]

Zitat:

Zitat von Sir Rufo (Beitrag 1280250)

Rein grundsätzlich betrachtet bietet es sich immer an, sowas nicht direkt von der Datenbank in ein Control zu pusten. Das verführt dann auch sehr leicht dazu in der Datenbank seltsame Strukturen zu erstellen (das passt besser zum Control) oder sich sonstwie zu stark an der Präsentation zu orientieren.

Dieses konkrete Projekt hier sieht sehr nach etwas komplexem aus ('Aufgabenplaner'). Da würde ich deinen Vorschlag unbedingt beherzigen.

Bei einfachen Darstellungen einer Datenmenge (aka 'Reports') wäre das ein absoluter Overkill. Dafür gibt es dann in SQL (siehe himitsu's Beitrag) die VIEWS, die hierfür vollkommen ausreichend sind. RAD muss ja nicht komplett abgeschafft werden. Insofern würde ich dein 'immer.. nicht' (=nie) relativieren. Eine VIEW kann ich in jedem datensensitiven Steuerelement ohne eine Zeile Code darstellen.

Immer den Weg wählen, der nachhaltig(!) am einfachsten ist.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1280269)

Insofern würde ich dein 'immer.. nicht' (=nie) relativieren. Eine VIEW kann ich in jedem datensensitiven Steuerelement ohne eine Zeile Code darstellen.

das klingt so als würdest Du Dich für Datensensitiven Controls einsetzen.
Darüber kann mann gewiss diskutieren, aber vor allem wenn ich hier viele Beiträge lese mein DBEdit, mein DBGrid mein DB... mag nicht, und einige davon scheinen dem Experimentierstadium schon etwachsen zu sein,dann kann nicht ernsthaft der Verwendung von Datensensitiven Controls zustimmen.

Was die VIEWs angeht bin ich zwar anderer Meinung (eine Query tut's auch) aber das ist eher Geschmackssache und teilweise auch vom Datenbanksystem abhängig.

Gruß
K-H

P.S.
Solange Du weißt was Du tust, nutz weiter DB...

[himitsu]

Vorteil Datenverwaltung, Datenspeicherung und Datenanzeige zu trennen:

Man kann an allen Stellen etwas austauschen
* andere Anzeigekomponente, wie z.B. eine Kalenderkomponente oder VCL/FMX/HTMLAusgabe
* andere Speicherung -> XML, INI, Webserver, anderes DBMS usw.

[Luckner]

Was stimmt nicht an der while-Schleife. Ohne Diese wird in einer Zelle der Text geschrieben. Mit der Schleife, gar nichts.

Delphi-Quellcode:

procedure TForm1.Gridfuellen();
begin
  DataModuleTODOList.IBDatabaseTODOList.Connected := true;
  Datamodule1.DataModuleTODOList.IBDataSet1.Open;
  Datamodule1.DataModuleTODOList.IBDataSet1.Close;
  Datamodule1.DataModuleTODOList.IBDataSet1.SelectSQL.Clear;
  Datamodule1.DataModuleTODOList.IBDataSet1.SelectSQL.Add('select * from EREIGNISSE where KW = ' + QuotedStr(LabelKW.Caption) + ' and JAHR = ' + LabelJahr.Caption + ' order by ZEILE, SPALTE');
  Datamodule1.DataModuleTODOList.IBDataSet1.Open;
  if Datamodule1.DataModuleTODOList.IBDataSet1.IsEmpty then
     begin
       ShowMessage('noch keinen Eintrag gefunden');
     end
  else
     begin
       Datamodule1.DataModuleTODOList.IBDataSet1.First;

       while Datamodule1.DataModuleTODOList.IBDataSet1.Eof do
          begin
            StringGrid1.Cells[Datamodule1.DataModuleTODOList.IBDataSet1ZEILE.AsInteger, Datamodule1.DataModuleTODOList.IBDataSet1SPALTE.AsInteger] := Datamodule1.DataModuleTODOList.IBDataSet1TEXT.Value;
            Datamodule1.DataModuleTODOList.IBDataSet1.Next;
          end;
     end;
end;

Luckner

[Dejan Vu]

Solange die Datenmenge am Ende ist, tue ...

Sollte es nicht heißen: Solange die Datenmenge NOCH NICHT am Ende ist?

[p80286]

while not (Datamodule1.DataModuleTODOList.IBDataSet1.Eof )

Gruß
K-H

Der rote Kasten ist in Urlaub!

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1280312)

das klingt so als würdest Du Dich für datensensitiven Controls einsetzen.

Solange es um die Anzeige geht, was spricht dagegen?

Zitat:

Was die VIEWs angeht bin ich zwar anderer Meinung (eine Query tut's auch)

Eigentlich schon, aber eine VIEW ist wiederverwendbar. Die Query natürlich auch, aber ich baue mir die Reports eben immer so, das man sie mit Fast/Crystal/SchießmichtotReport oder direkt in EXCEL abbilden kann, ohne dafür den Report-Quelltext zu haben (oder -Gott bewahre-) in den Quelltext der Anwendung rein muss. Wenn ich die Query kopiere und es ändert sich eine Geschäftsregel, hab ich Pech. Eine View ist zudem auch als Quelle für komplexere Report nützlich und und und. Du schreibst ja auch Prozeduren und verwendest kein Copy&Paste.

Zitat:

Solange Du weißt was Du tust, nutz weiter DB...

Keine Bange. Man bekommt ja keine Pickel, wenn man DB-Controls verwendet.

Bau mal eine komplexe Eingabe mit einem DevExpress-Grid als RAD (und dahinter eine updatetable View :mrgreen:) zum einen und dann das gleiche toll mit TList<TFooBar> und persistenzschicht und manuellem Füllen (bloß keine DB-VCL) und und und. Also bei mir geht das in ein paar Minuten und solange Du noch rumtippst, um keine Pickel zu bekommen, bin ich schon auf dem Golfplatz/am Strand/an der Bar.

Wie gesagt: Ich weiß, was ich tue. Sollte man eh, meinste nich?

[Luckner]

Danke für die Hilfe. Je später der Abend, desto mehr Bretter vor den Augen. Ärgerlich.

Danke, Luckner