<\/p>\n
Die Summen von Zahlen in bestimmten Feldern innerhalb von Gruppierungen zu ermitteln, ist kein Hexenwerk. Manchmal benötigen Kunden aber Spezialanforderungen, die sich mit üblichen Mitteln nicht mehr bewerkstelligen lassen. Zum Beispiel das Bilden von Gruppensummen ohne das Vorhandensein von Gruppen. Der vorliegende Beitrag zeigt, wie dies funktioniert.<\/b><\/p>\n
Neulich erreichte mich die Anforderung, für eine Liste von Elementen bestimmter Kategorien die Anzahl der Elemente je Kategorie auszugeben – allerdings nicht im Rahmen einer Gruppierung im Gruppenfuß, sondern ohne Gruppierung im Seitenfuß. Konkret ging es um die Ausgabe von Präsenten für Mitarbeiter, wobei die Mitarbeiter nicht nach Präsent gruppiert, sondern nach Alphabet, Alter oder sonstigen Kriterien sortiert werden sollten. Prinzipiell soll der Bericht also wie in Bild 1 aussehen.<\/p>\n
![\"pic001.png\"](\"..\/fileadmin\/_temp_\/2010_02\/GruppensummeOhneGruppe-web-images\/pic001.png\")
<\/p>\n
Bild 1: Anzahl von Gruppierungselementen ohne Aktivierung der Gruppierung<\/span><\/b><\/p>\n Die Lösung ist nicht ganz trivial, denn die Anzahl der verschiedenen Präsente kann sich ändern. Es wäre somit kein guter Stil, einfach für jede Präsentart ein Bezeichnungsfeld im Berichtsfuß zu platzieren und ein entsprechendes Textfeld mit der Anzahl zu füllen. Das Problem hierbei wäre, dass Sie jedes Mal, wenn ein Präsent hinzukommt oder wegfällt, in den Entwurf des Berichts eingreifen müssten.<\/p>\n Das Beispieldatenmodell sieht wie in Bild 2 aus und besteht aus einer Mitarbeiter- und einer Präsente-Tabelle. Also brauchen wir eine dynamische Lösung, die sich an den vorhandenen Präsentarten orientiert und je Präsent eine Zeile im Berichtsfuß erzeugt. Dies gelingt nur mit einem Unterbericht zuverlässig. Diesem weisen Sie als Datenherkunft eine Abfrage basierend auf den einzigen beiden Tabellen des Datenmodells zu. Den Bericht selbst erleichtern Sie um Seitenkopf und -fuß sowie um Berichtskopf und -fuß und fügen eine Gruppierung nach dem Feld PraesentID <\/b>hinzu. Diese soll keinen Kopfbereich, aber einen Fußbereich enthalten. Dann minimieren Sie den Detailbereich, indem Sie seine Eigenschaft Höhe <\/b>auf 0 <\/b>einstellen oder den unter dem Detailbereich liegenden Gruppenfuß so weit nach oben schieben, dass der Detailbereich nicht mehr sichtbar ist. Im Gruppenfuß schließlich fügen Sie das Feld Praesent<\/b> aus der Feldliste des Berichts ein. Ergänzen Sie diesen Bereich um ein weiteres Textfeld namens txtAnzahlPraesente<\/b>, dessen Eigenschaft Steuerelementinhalt <\/b>Sie auf den Wert =Anzahl(PraesentID) <\/b>festlegen. Der Berichtsentwurf sollte nun wie in Bild 3 aussehen.<\/p>\n Bild 2: Datenmodell der Beispieldatenbank<\/span><\/b><\/p>\n Bild 3: Entwurf des Unterberichts zur Anzeige der Anzahl je Präsent<\/span><\/b><\/p>\n <\/p>\n Dies funktioniert: Der Unterbericht zeigt nun wie gewünscht die Anzahl der einzelnen Präsente für die Mitarbeiter an. Ein kleines Problem bleibt dennoch: Was, wenn der Benutzer den Bericht filtert, indem er ihn beispielsweise mit folgender Anweisung öffnet:<\/p>\n Dann wird zwar der Hauptbericht gefiltert, aber der Unterbericht zeigt nach wie vor die Auflistung aller Präsente an. Dem helfen wir ab, indem wir die Datenherkunft des Unterberichts an die des Hauptberichts anpassen und gleichzeitig eventuell übergebene Filterkriterien berücksichtigen. Dies ist möglich, weil ein etwa per WhereCondition <\/b>über die DoCmd.OpenReport<\/b>-Methode übergebenes Kriterium in die Eigenschaft Filter <\/b>des Berichts geschrieben wird.<\/p>\n Damit sich der Unterbericht diesen Filter ebenfalls anzieht, verwenden wir seine Beim Öffnen<\/b>-Ereigniseigenschaft und legen dafür die folgende Ereignisprozedur an:<\/p>\n Diese prüft zunächst, ob es sich bei der Datenherkunft des Hauptberichts, die wir der Eigenschaft RecordSource <\/b>des Parent<\/b>-Elements des aktuellen Unterberichts entnehmen, um eine SELECT<\/b>-Anweisung oder um eine gespeicherte Abfrage oder gar eine Tabelle handelt. Tritt Letzteres ein, formulieren wir mithilfe des Namens der Tabelle oder Abfrage eine entsprechende SELECT<\/b>-Anweisung. So wird etwa aus qryPraesente <\/b>der Ausdruck SELECT * FROM qryPraesente<\/b>.<\/p>\n Danach prüft die Prozedur, ob das Hauptformular einen Filter enthält. Falls ja, ist eine weitere Untersuchung nötig: Wenn die Eigenschaft Datenherkunft <\/b>eine SELECT<\/b>-Anweisung und keine Tabelle oder Abfrage enthält, könnte diese selbst bereits eine WHERE<\/b>-Bedingung enthalten. Dieser fügen wir das Kriterium aus der Filter<\/b>-Eigenschaft natürlich nicht mit dem führenden Schlüsselwort WHERE <\/b>an, sondern mit dem Schlüsselwort AND<\/b>. Nur wenn der SQL-Ausdruck das Schlüsselwort WHERE <\/b>noch nicht enthält, soll das Kriterium um dieses Schlüsselwort ergänzt werden.<\/p>\n Damit sind wir auch schon fertig: Der Unterbericht zeigt nun die gefilterte Anzahl der Präsente jeder Sorte an. Es gibt sicher Datenherkünfte, die sich durch unsere Prozedur nicht fehlerfrei erweitern lassen, aber wenn Sie die grundsätzliche Vorgehensweise verstanden haben, können Sie diese auch auf Berichte mit komplizierteren Datenherkünften übertragen.<\/p>\n Enthaltene Beispieldateien:<\/p>\n GruppensummeOhneGruppe.mdb<\/p>\n![\"pic002.png\"](\"..\/fileadmin\/_temp_\/2010_02\/GruppensummeOhneGruppe-web-images\/pic002.png\")
<\/p>\n![\"pic003.png\"](\"..\/fileadmin\/_temp_\/2010_02\/GruppensummeOhneGruppe-web-images\/pic003.png\")
<\/p>\nDoCmd.OpenReport "rptPraesente", acViewPreview, WhereCondition:="MitarbeiterID = 1"<\/pre>\n
Private Sub Report_Open(Cancel As Integer)\r\n Dim strSQL As String\r\n If Left(Me.Parent.RecordSource, 6) = _\r\n "SELECT" Then\r\n strSQL = Me.Parent.RecordSource\r\n Else\r\n strSQL = "SELECT * FROM " & _\r\n Me.Parent.RecordSource\r\n End If\r\n If Len(Me.Parent.Filter) Then\r\n If InStr(1, strSQL, " WHERE ") > 0 Then\r\n strSQL = strSQL & " AND " & _\r\n Me.Parent.Filter\r\n Else\r\n strSQL = strSQL & " WHERE " & _\r\n Me.Parent.Filter\r\n End If\r\n End If\r\n Me.RecordSource = strSQL\r\nEnd Sub<\/pre>\n
Downloads zu diesem Beitrag<\/h3>\n