Benutzer mit den meisten Antworten
report mit subreports bleibt leer nur bei den letzten Datensätzen

Frage
-
Hallo,
ich nutze A2007, die Daten liegen auf einem SQL Server 2008R2 backend und werden per ODBC verknüpft.
Folgenden Bericht hab ich erstellt:
Wenn ich Daten abrufe aus dem Jahr 2008 (Beginn der Datenaufzeichnung), dann zeigt der Bericht alles sauber an.
Wie zu sehen ist, wird derselbe subrpt für jeden Wochentag einmal aufgerufen. Dabei werden im Ereignis Report_Open des subreports die Daten gefiltert mit:
strSQL = "SELECT *" & _ " FROM " & gcAppQry4612 & _ " WHERE [Kalenderjahr] = " & mvarJahr & _ " AND [KalenderWoche] = " & mvarWoche Me.Recordsource = strSql
Daten ab dem Jahr 2010 werden nicht mehr angezeigt, d.h. der subreport bleibt leer. Die Jahre 2008 und 2009 sind ok. Ich habe keine Idee, woran das liegen kann.
vg
candide
-- candide
- Bearbeitet candide Mittwoch, 24. September 2014 20:30 Screenshot verbessert
Antworten
-
So,
Fehler gefunden. Die Link-Felder zum Subreport waren nicht sauber, weil im parent report die Kalenderwoche für das Jahr 2010 falsch errechnet wurde.
KalWoche: ZInteger(Format([P1P2_Schichtdatum];"ww";2))
liefert NICHT die korrekte KW. Ich habe schon eine Routine, die die deutsche KW korrekt berechnet, die werde ich einsetzen und gut iss.
Danke an alle Poster,
-- candide
Alle Antworten
-
wenn ich Daten abrufe aus dem Jahr 2008 (Beginn der Datenaufzeichnung), dann zeigt der Bericht alles sauber an.
Wie zu sehen ist, wird derselbe subrpt für jeden Wochentag einmal aufgerufen. Dabei werden im Ereignis Report_Open des subreports die Daten gefiltert mit:
strSQL = "SELECT *" & _ " FROM " & gcAppQry4612 & _ " WHERE [Kalenderjahr] = " & mvarJahr & _ " AND [KalenderWoche] = " & mvarWoche Me.Recordsource = strSql
Daten ab dem Jahr 2010 werden nicht mehr angezeigt, d.h. der subreport bleibt leer. Die Jahre 2008 und 2009 sind ok. Ich habe keine Idee, woran das liegen kann.
Hallo candide,
hast du dir schon mal die Daten in der/den Tabelle/n angeschaut? Sind die ok?
Füge mal ein
Debug.Print strSql
vor dem Me.Recordsource ein.
Das SQL-Statement siehst du dann im Direktfenster. Kopiere den String dann in eine Abfrage (SQL-Ansicht).
So kannst du schauen wo das Problem liegt ... falls es nicht schon im SELECT erkennbar ist.
Viele Grüße Stefan
- Bearbeitet Stefan Wirrer Donnerstag, 25. September 2014 06:43
-
Hallo Stefan,
die zugrundeliegende query gcAppQry4612 kann ich einfach öffnen und da sind alle knapp 6.000 Datensätze sauber drin. Die WHERE-clause filtert nach Jahr und Woche, um den Start des Reports schneller zu machen.
Ursprünglich lief der Report OHNE die WHERE-clause, und auch da war dieser Fehler noch drin.
-- candide
- Bearbeitet candide Donnerstag, 25. September 2014 13:12
-
die zugrundeliegende query gcAppQry4612 kann ich einfach öffnen und da sind alle knapp 6.000 Datensätze sauber drin. Die WHERE-clause filtert nach Jahr und Woche, um den Start des Reports schneller zu machen.
Ursprünglich lief der Report OHNE die WHERE-clause, und auch da war dieser Fehler noch drin.
Hallo candide,
hast du dir mal den SELECT angeschaut (als Abfrage) den strSql liefert?
Falls der iO ist, dann hast du vermutlich im Report noch irgendwo einen zusätzlichen Filter drinnen.
Viele Grüße Stefan
-
So,
Fehler gefunden. Die Link-Felder zum Subreport waren nicht sauber, weil im parent report die Kalenderwoche für das Jahr 2010 falsch errechnet wurde.
KalWoche: ZInteger(Format([P1P2_Schichtdatum];"ww";2))
liefert NICHT die korrekte KW. Ich habe schon eine Routine, die die deutsche KW korrekt berechnet, die werde ich einsetzen und gut iss.
Danke an alle Poster,
-- candide