Stringgrid aus Datenbank füllen

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

* 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 von Luckner:

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

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 von Dejan Vu:

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.

[Dejan Vu]

Zitat von p80286:

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 ) 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?