mehrere Spalten in Ergebnismenge

[sx2008]

Also ich würde das Problem mit einem Memory-Dataset lösen.
Schritt 1:
man benötigt eine Abfrage gruppiert und sortiert nach ArtikelNr, Jahr und Monat:

Code:

ArtikelNr  | Jahr  | Monat | Summe   | MaxWert | Anzahl 
=============================================================
 100      | 2011 | 1     | 6785.70 | 559.00  | 44
 100      | 2011 | 3     | 2782.50 | 120.0   | 17
....

Zusätzlich zur Summe des Preises habe ich noch den Max. Artikelbetrag und die Anzahl aufgenommen.
Die weiteren Felder bekommt man quasi zum Nulltarif und kann damit später interessante statische Daten anzeigen.

Schritt 2:
Man erzeugt dynamisch zur Laufzeit die Felder für das Memory-Dataset.
Das Memory-Dataset stellt dann die Pivot-Tabelle dar.
Dazu muss man in einer Schleife über alle Datensätze der obigen Abfrage laufen und ein neues Feld vom Typ Currency erzeugen.
Man erzeugt z.B. beim Datensatz für Jahr=2011 und Monat=3 das Feld "J2011M03" oder man macht es so wie man es eben benötigt.
Es muss aber geprüft werden, ob das Feld schon angelegt ist.
Im Event AfterOpen des Memory-Datasets kann man den Feldern über das Property DisplayLabel lesbare Bezeichnungen geben.

Schritt 3:
In einer weiteren Schleife (2. Durchlauf) über alle Datensätze wird das Memory-Dataset befüllt.
Dabei muss man prüfen, ob schon ein Datensatz zum Artikel existiert.
Falls nein mit Append einen neuen Dataset anlegen; falls ja Datensatz mit Edit verändern.
Man hat jetzt die Möglichkeit die Summe, MaxWert, Anzahl oder Durchschnitt in das Memory-Dataset zu schreiben.

Vorteile:
* maximale Flexibilität (kein Problem die Daten quartalsweise oder je Kalenderwoche zu präsentieren)
* Unabhängigkeit von der Datenbank
* wesentlich einfachere SQL-Abfrage (schneller und einfacher zu verstehen)
* SQL-Abfrage kann leichter mit einer einschränkenden WHERE-Bedingung erweitert werden
* Grundprinzip ist leicht auf andere Tabellen (Bestellungen, Rückläufer,...) umsetzbar
Nachteil:
* man benötigt ein Memory-Dataset und geschätzte 50 bis 100 Zeilen Sourcecode zur Umsetzung

Man könnte eine Klasse schreiben, die die Schritte 2 und 3 konfigurierbar und allgemeingültig umsetzt.

[Hansa]

Ich war schon kurz davor, das mit einem Clientdataset (CDS) zu realisieren bzw. war das schon so weit fertig. Das war aber nur so, weil es mir anfangs nicht gelang, mehr als ein Jahr in die Ergebnismenge reinzukriegen (also 24 Felder in eine Zeile). Auch war das problematisch, wenn bei einem Artikel ein ganzes Jahr fehlt. Und so etwas

Code:

SUM (CASE JAHR WHEN 2012 THEN CASE (Monat WHEN 1...)

also geschachtelt, das geht nun mal nicht. Zumindest nicht mit Firebird. Daher ja auch mein Kunstgriff mit dem 1||:AUSGJAHR etc. Wenn so was geschachtelt mit 2 Feldern nicht geht, dann werden eben aus 2 Feldern eines gemacht und fertig. Das war der Trick. Allerdings hat der auch das ClientDataSet an dieser Stelle überflüssig gemacht.

Jetzt wird zuerst mal alles absolut wichtige aus der DB gelesen, das heisst die entsprechenden Artikelnummern und eben 24 Umsatzzahlen. Eventuell wird damit allerdings dann doch wieder ein CDS bestückt. Da muss man mal noch sehen. Jedenfalls ist jetzt eines sichergestellt : zu jedem Artikel gehört (und es ist auch sichergestellt, dass nichts fehlt) eine Reihe von Zusatzdaten, also in dem Fall 24 Zahlen. Auch ohne CDS ist das bereits jetzt sehr flexibel.

Die Grunddaten sind jedenfalls nun vorteilhaft aufbereitet verfügbar und es stellt sich nur noch die Frage, ob mehr Logik bzw. Daten in die stored Procedure verlagert wird, oder lieber ins eigene Programm (z.B. Sortierung, Berechnungen etc.).

Vielleicht ist allerdings noch das angesprochene Memory-Dataset für den einen oder anderen nicht so geläufig. Der Begriff ist zwar so verständlicher, aber dabei handelt es sich in Delphi um ein ClientDataSet (das kann allerdings noch mehr). D.h., man definiert sich mit ein paar Zeilen im eigenen Programm eine eigene Tabelle, die es in keiner DB gibt, behandelt die aber so, als ob das ein "richtiges" Dataset sei. D.h. zum Bsp., dass man diese Quasi-DB-Tabelle in einem DBGrid oder in Reports verwenden kann. Ist auf jeden Fall leichter zu behandeln als richtige DB und kennt mehr Datentypen. Ich empfehle mal jedem, sich das näher anzuschauen, der das so noch nicht kennt. Denn : wer hier in der DP oder in anderen Foren mal nach ClientDataset sucht, der wird nicht soviel finden. Das könnte den Eindruck erwecken, dann wäre das auch nicht so wichtig, aber das ist nicht so ! Die letzte Zeit war ich auf ziemlich vielen Konferenzen u.ä. Ekon, Firebird-Konferenz, Delphi-Tage... Da lief mir überall ein ClientDataset über den Weg. Ich war da schon etwas verwundert.