Oktober 29, 2020, 21:43:45

Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!


Erstellen eines dynamischen Berichts aus Abfrage (Kreuztabelle)

Begonnen von SSSleep, Mai 20, 2020, 14:26:36

⏪ vorheriges - nächstes ⏩

SSSleep

Mai 20, 2020, 14:26:36 Letzte Bearbeitung: Mai 20, 2020, 15:00:12 von SSSleep
Hallo,

ich bin schlichtweg am verzweifeln. Meine Versuche einen Bericht aus einer Abfrage (als Kreuztabelle) zu genieren scheitern alle früher oder später. Ich habe dabei zwei Anforderungen:

  • in der Abfrage soll eine Selektion der Datensätze über "Kriterium" erfolgen

  • vorzugsweise wären die Kriterien in der Abfrage als Parameter auszuführen

  • die Spaltenfelder in der Abfrage sind variabel, daher möchte ich beim Öffnen des Berichtes vorgesehen Leerfelder belegen



Im ersten Schritt habe ich in der Abfrage das Kriterium fest eingetragen. Im Sub Report_Open öffne ich dann ein Recordset auf die Abfrage und weise meinen Berichts-Feldern die Spalten der Abfrage zu. Bis dahin Funktioniert es wunderbar.

Im zweiten Schritt möchte ich meine Kriterien mittels Parameter an die Abfrage übergeben. Also trage ich in den Kriterien meinen Parameter ein. Da man wohl bei Kreuztabellen zusätzlich den Datentyp des Parameters Kennzeichnen muss, trage ich in der Abfrage auch noch den Parameter und Datentyp unter Eigenschaften->Parameter ein.

Zurück in meinem Bericht erwartet der Recordset beim Öffnen nun den Parameter. Also erstelle ich zunächst ein QueryDef und weise dort den Parameter zu. Nun öffne ich mein Recordset auf Basis des erstellten QueryDef.

Und nun scheitere ich :(
Der Bericht hat zusätzlich ebenfalls die Abfrage als Recordsource zugewiesen und öffnet seinerseits noch einmal die Abfrage. Dies dann allerdings ohne die Parameter. Meine Versuche dem Bericht das zuvor geöffnete Recordset zuzuweisen scheitern. Das scheint bei Berichten wohl nicht zu gehen.

Umgekehrt könnte ich auch damit leben, wenn die Abfrage über die Recordsource des Berichtes und somit ohne Paramterübergabe geöffnet würde. Die Parameter würde ich dann in der Meldung der Abfrage eingeben. Allerdings komme ich auch im Sub Report_Open auch nicht an das Recordset des Berichts um dann meine Felder zu füllen.

Ist das soweit nachvollziehbar? Wäre toll, wenn mir jemand helfen könnte.

Edit:
Wäre es denkbar die Abfrage aus einem Formular heraus zu parametrieren und dann die parametrierte Abfrage an den Bericht zu übergeben?

Ralf


DF6GL

Hallo,
Zitat
Wäre es denkbar die Abfrage aus einem Formular heraus zu parametrieren und dann die parametrierte Abfrage an den Bericht zu übergeben?


Ja.

Eine Methode:

Erstelle eine Abfrage, die alle benötigten Daten in gewünschter Zusammenstellung liefert. Im Abfrageentwurf fügst Du die  Bedingung  1=1   ein  (Feld:  Ausdruck1:  1   Kriterium: 1).   Falls die KT-Abfrage fixierte Spalten benötigt, kann die "IN"-Klausel ebenso durch einen Platzhalter ersetzt werden.
Den SQL-String dieser Abfrage (SQL-Ansicht)  weist Du in einer VBA-Prozedur einer Variablen ("strSQL") zu.
Der Bericht erhält die selbe Abfrage als Datenherkunft und wird nach dieser Datenkonstellation aufgebaut.

Im weiteren Verlauf der Prozedur kann jetzt der Kriteriums-Platzhalter (in SQL:  ((1)=1)  )  mit Hilfe der Replace-Funktion durch das aktuelle Kriterium  (die IN-Anweisung ebenso) in der Variablen strSQL ersetzt werden.

Danach wird der so geänderte SQL-String der Abfrage-Eigenschaft .SQL  zugewiesen. Bei Öffnen des Berichtes liefert nun die Abfrage die gewünschten Daten an den Bericht.

SSSleep

Hallo Franz,

das verstehe ich soweit. Kannst du mir noch einen Tipp geben, wie ich die SQL Anweisung aus der Abfrage auslese und vor allem wie ich hinterher der Abfrage-Eigenschaft .SQL den String wieder zuweise?

Vielen Dank

Ralf

DF6GL

Hallo,

Dim strSQL as String
strSQL = Currentdb.Querydefs!qry_Berichtsabfrage.SQL



oder unter "Abfrageentwurf/SQL-Ansicht" String kopieren

Dieser String sollte aber als Literal in die Prozedur gestellt werden.


Zuweisen:

'strSQL  modifizieren
Currentdb.Querydefs!qry_Berichtsabfrage.SQL =strSQL

SSSleep

Hallo Franz,

vielen Dank, deine Lösung funktioniert soweit. Allerdings hat sie für mich die große Einschränkung, dass ich die Abfrage dauerhaft ändere. Dafür sehe ich zwei Lösungen, die aber beide nicht so glücklich sind:

  • Ich speichere den Default-SQL-Ausdruck dauerhaft in der VBA Prozedur
    - bei kleineren Anpassungen an der Abfrage muss auch die VBA Prozedur mitgezogen werden

  • Nach dem Erstellen des Berichts wird der Default Platzhalter (in SQL:  ((1)=1)  ) wieder in die Abfrage geschrieben
    -wenn beim Bericht erstellen etwas schief läuft und die Prozedur vorzeitig abgebrochen wird, dann ist meine Default Abfrage "zerstört"



Hast du evtl. noch einen alternativen Ansatz?

Vielen Dank für deine Geduld

Ralf

ebs17

Mit freundlichem Glück Auf!

Eberhard

DF6GL

Hallo,
1)  SQL-String in der VBA-Prozedur:  So ist es auch (hier) gedacht

Um das zu vermeiden, erstelle eine weitere Abfrage "qry_KT_Init", die wie vorher angegeben die gewünschten Daten liefert und die 1=1-Bedingung enthält.
In der Prozedur liest Du den SQL-String aus der Abfrage aus, anstatt ihn als Literal-String zu speichern.

strSQL = Currentdb.Querydefs!qry_KT_Init.SQL

Danach geht es weiter wie beschrieben.

2) verstehe ich nicht..  Die Berichtsabfrage wird ja mit der aktuellen Where-Condition erweitert. Danach wird nichts weiter verändert oder zerstört.


Beaker s.a.

Hallo Ralf,
Zitat1.Ich speichere den Default-SQL-Ausdruck dauerhaft in der VBA Prozedur

Ich würde ihn in einer öffentlichen Property zwischenspeichern.
gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

DF6GL

Hallo,

Zitateiner öffentlichen Property zwischenspeichern.


Das würde aber auch nicht viel helfen, derweil der String dann ja auch manuell bei Bedarf anzupassen ist und nicht über den Abfrage-Entwurf "beklickt" werden kann.


BTW: Eberhard hat ja eine andere Methode angesprochen.