Ein Query auf drei Grids verteilen

[Mike_on_Tour]

Hallo zusammen,

ich habe ein Query und möchte die Datenmenge auf drei DBGrids aufteilen. Als Kennzeichen für die Aufteilung soll ein Feld in der Datenmenge dienen. Da ich jetzt schon ein paar erfolglose Versuche hinter mir habe, hier die Frage, ob das überhaupt geht.

mfG
Mike

[mkinzler]

Da wäre es ja sinnvoller 3 Queries zu verwenden

[Mike_on_Tour]

Ist das nicht etwas viel Aufwand für eine "einfache" Aufteilung der Daten ?
Könnte man nicht einen Filter auf das DBGrid setzen ?

[RavenIV]

Du kannst dem DBGrid schon irgendwie mitteilen, welche Spalten es anzeigen soll.

Aber das mit den drei Queries finde ich auch besser.

[joachimd]

Zitat:

Zitat von Mike_on_Tour

ich habe ein Query und möchte die Datenmenge auf drei DBGrids aufteilen. Als Kennzeichen für die Aufteilung soll ein Feld in der Datenmenge dienen. Da ich jetzt schon ein paar erfolglose Versuche hinter mir habe, hier die Frage, ob das überhaupt geht.

Eine vertikale Aufteilung bekommst du relativ einfach hin, indem du auf dem Grid mit einem Doppelklick in die Feldliste gehst und nur ein paar Felder davon auswählst.
So wie ich dein Posting aber verstehe, willst du eine horizontale Aufteilung (keine Selektion der Felder, sondern der Datensätze) anhand des Inhaltes eines der Felder!? In diesem Fall folge dem Rat der anderen und schreib 3 Queries.

Nachtrag: Du kannst auf eine AdsQuery auch einen Filter anlegen, aber das betrifft dann alle drei Grids gleichermaßen. Ein Grid kann nicht filtern, nur die zugrundeliegende Datenmenge.

[Mike_on_Tour]

Zitat:

Zitat von RavenIV

Du kannst dem DBGrid schon irgendwie mitteilen, welche Spalten es anzeigen soll.

Du meinst sicherlich "Zeilen" ?

Zitat:

Zitat von joachimd

So wie ich dein Posting aber verstehe, willst du eine horizontale Aufteilung (keine Selektion der Felder, sondern der Datensätze) anhand des Inhaltes eines der Felder!?

Genau SO hatte ich das vor.

Zitat:

Zitat von joachimd

Du kannst auf eine AdsQuery auch einen Filter anlegen, aber das betrifft dann alle drei Grids gleichermaßen. Ein Grid kann nicht filtern, nur die zugrundeliegende Datenmenge.

Ja, das habe ich auch ausprobiert, aber der Filter gilt dann auch für alle Grids.

Meine Lösung sieht jetzt so aus: Ich habe das EINE Query und durchlaufe die gesamte Datenmenge (WHILE ...). In einer Spalte der Datenmenge steht ein Wert. In Abhängigkeit von diesem Wert befülle ich dann drei StringGrids. Da die Daten nur angezeigt werden sollen, ist das sicher einfacher, als drei fast gleiche Queries mit drei anhängenden DBGrids und drei DataSources zu verwenden. Man stelle sich mal vor, ich müßte die SQL-Abfrage (so etwa 100 Zeilen mit Parameter und Unions) ändern. So habe ich nur eine Änderung statt drei zu machen.

Mike

[RavenIV]

Richtig.
StringGrid selber befüllen ist auch ne gute Alternative.

[alzaimar]

How to cook drei Grids aus einer Query.

1x query
3x TProvider (an die query beppseln)
3x TClientDataset (mit individuellen filtern)

3x Tdatasource an die TClientDatasets
3x TDBGrid an die TDatasourcen

Tipp: Die Reihenfolge, wie man die Clientdatasets und die Query öffnet und schließt ist entscheidend. WEnn man zur Designzeit damit rumspielt, immer wieder die TClientdatasets per Rechte-Maus-Taste leeren (Clear Data oder so)

3 Queries wären zwar einfacher, aber wenn die Query an sich schon aufwändig ist, ist meine Lösung performanter.

[joachimd]

Zitat:

Zitat von Mike_on_Tour

Meine Lösung sieht jetzt so aus: Ich habe das EINE Query und durchlaufe die gesamte Datenmenge (WHILE ...). In einer Spalte der Datenmenge steht ein Wert. In Abhängigkeit von diesem Wert befülle ich dann drei StringGrids. Da die Daten nur angezeigt werden sollen, ist das sicher einfacher, als drei fast gleiche Queries mit drei anhängenden DBGrids und drei DataSources zu verwenden. Man stelle sich mal vor, ich müßte die SQL-Abfrage (so etwa 100 Zeilen mit Parameter und Unions) ändern. So habe ich nur eine Änderung statt drei zu machen.

Sicherlich einfacher in der Anwendung, aber auch performanter? Bei großen Ergebnismengen musst du mit deiner Methode alle Datensätze abholen, bevor du etwas anzeigen kannst. Mit drei Queries siehst du schon was, wenn die ersten 10-20 Datensätze bereit sind. Der Rest wird eh nach Bedarf ermittelt (Ausnahmen bestätigen die Regel).

[hoika]

Hallo,

das mit 100 Zeilen ändern -> grosser Aufwand kann ich nicht so gelten lassen.
Du kannst ja eine CreateQuery(TheQuery: TAbsQuery) schreiben.
Die erzeugt den Query-Text (per SQL.Add) für die 3 Queries.


Heiko

[p80286]

@Joachimd

Hallo ,

die Lösung von Mike_on_Tour (eine Query, drei StringGrids) verwende ich auch. Weil
1) meistens muß ich die Query-Ergebnisse erst noch durch die Datenmühle drehen, bevor ich sie anzeige,
2) ich wollte das "Datenholen" von der Oberfläche entkoppeln, damit ich mit gleicher Oberfläche mehrere unterschiedliche DBs bedienen kann,
3) "das bischen verteilen" erledigt mein PC schneller als die Daten hereintröpfeln und (ich bin mir nicht ganz sicher, aber irgendwo hab ich das schonmal hingekriegt) mit application.processmessages bekommt man eine Anzeige bevor alle Daten im Stringgrid eingefügt sind.

Gruß
K-H

[mkinzler]

Zitat:

1) meistens muß ich die Query-Ergebnisse erst noch durch die Datenmühle drehen, bevor ich sie anzeige,

Das würde ich, soweit möglich, in der Abfrage machen.

Zitat:

2) ich wollte das "Datenholen" von der Oberfläche entkoppeln, damit ich mit gleicher Oberfläche mehrere unterschiedliche DBs bedienen kann,

Noch ein Grund, so viel wie möglich ins DBMS zu verlagern (Views, SP)