Access druckt alle Datensätze aus der Tabelle anstatt Bericht

[JOG]

Hallo Access-Profis

Habe ein ganz eigenartiges Phänomen, welches ab und zu auftritt. In einem Formular gebe ich verschiedene Datensätze ein (Artikel, Produktionsdatum, Chargen-Nr.) zu denen ich in einem nachfolgenden Bericht Etiketten erstellen lasse. Nun kommt es ab und zu vor, dass wenn ich die Etiketten der ausgewählten Datensätze via Seitenansicht drucken will, der Druckmanager anstatt die eine Seite mit Etiketten dann sämtliche Datensätze der zugrunde liegenden Tabelle tabellarisch ausdruckt  Dieser Fehler tritt lediglich sporadisch auf und ist auch beim Ausdruck von einem Bericht in einem anderen Zusammenhang ab und zu festzustellen (wenn's dumm kommt, werden dann da anstatt eine Seite halt bis zu 20 und mehr ausgedruckt .

WEiss jemand, an was das liegen könnte? Da es bei mehreren Berichten vorkommt, frag ich mich, ob's mit der Systemumgebung vom PC oder Drucker zu tun haben könnte.

Danke für Eure Inputs.

Gruss JOG

[DF6GL]

Hallo,

hört sich mysteriös an...


1)  Wie lautet die Datenherkunft des Berichtes (bei einer Abfrage deren SQl-String) ?
2) Wie wird der Bericht überhaupt aufgerufen?
3) "... die Etiketten der ausgewählten Datensätze ... " WIE werden diese Datensätze ausgewählt?


Falls die DB "zerschossen" sein sollte, hilft evtl. , eine neue leere DB anzulegen und darin alle Objekte aus der alten zu importieren.
Auch könnte der Access-Startparameter "/decompile"  hilfreich sein.


Wenn nichts von all dem hilft, lad die DB hier hoch (datenreduziert und gezippt) damit man sich die Sachlage genau ansehen kann.

[database]

Hallo,

gibt es einen Unterschied im Verhalten, wenn du den Bericht zuerst in der Berichtsansicht öffnest und dann in die Seitenvorschau wechselst und wenn du den Bericht per Rechtsklick aus dem Objektfenster in die Seitenansicht beförderst und wenn der Bericht 'ganz normal' aufgerufen wird (z.B. aus einem Formular?
Enthält der Bericht irgendwelche VBA-Codes?

Wie Franz schon angemerkt hat ... wie wird der Bericht überhaupt aufgerufen?
    Ist auch mitentscheidend zu meiner ersten Frage zu sehen.

[JOG]

Hallo und guten Abend

Ja die Berichte haben teilweise verschiedene Codes und Funktionen hinterlegt. Das verwunderliche an der Sache ist, dass beim schliessen und erneuten öffnen der DB der Fehler bis zum nächsten Mal verschwunden ist (ist auch der Fall, wenn ich kurz in die Entwurfsansicht des frm wechsle...
Das Verhalten des Fehlers in den verschiedenen Berichtsansichten muss ich erst noch testen, da kann ich noch nichts dazu sagen.

Zu Frage 1: Datenherkunft aus Abfrage
2: Der Bericht wird via Schaltfläche und docmd.-Befehl aufgerufen => "Ansicht Seitenansicht"
3: Daten werden einerseits mittels eines Kontrollfeldes ausgewählt und alle Daten mit Kontrollfeld "JA" ausgedruckt. Andererseits drucke ich im anderen Fall ein Report aus anhand eines bearbeiteten, aktuellen Datensatzes im Formular.

Helfen diese Angaben weiter?

Gruss JOG

[DF6GL]

Hallo


nur bedingt....


Wie lautet der SQL-String der Abfrage?

Benutzt Du ein Makro oder VBA-Code für den Berichtsaufruf? Wie lauten ALLE angebenen Parameterwerte für die Docmd-Methode?

Zu 3).  ok.





Es bleibt:  Vermutlich ist die DB zerschossen. Das kann auch nur heißen, dass lediglich eine Tabelle "unsaubere" Daten enthält, bzw. strukturell beschädigt ist.

[JOG]

Guten Morgen

Dies ist der SQL-String der zugehörigen Abfrage:

SELECT Bulkchargen.DatumHerstellung, Bulkchargen.ArtikelNr, Artikelliste.Artikelbezeichnung, Bulkchargen.[Chargen-Nr], Bulkchargen.EtikettenDruck
FROM Bulkchargen INNER JOIN Artikelliste ON Bulkchargen.ArtikelNr = Artikelliste.ArtikelNr
WHERE (((Bulkchargen.EtikettenDruck)=Yes));

Der VBA-Code für den Berichtsaufruf lautet:
DoCmd.OpenReport "Berichtetikettenbulk", acViewPreview, "", "", acWindowNormal

Was wäre Deiner Meinung nach das Beste, wenn die DB zerschossen sein sollte? Hast Du eine Vermutung bezüglich "unsaubere Daten" resp. "strukturell beschädigt"?

Gruss JOG

[DF6GL]

Hallo,


schreib mal im SQl-String:

WHERE Bulkchargen.EtikettenDruck <> 0




Die Antwort zur beschädigten DB hast Du schon erhalten.


Hier weitere Tipps:

http://www.donkarl.com/?FAQ1.27

[JOG]

Hallo

Leider auch nicht erfolgreich. Habe die Where-Klausel auf<>0 angepasst, jedoch ohne Erfolg. Das einzige scheinbar wirksame war bisher den Einbau des folgenden Codes vor dem Öffnen des Berichts:

DoCmd.OpenForm "Erfassen Bulkchargen", acDesign, "", "", , acWindowNormal
DoCmd.OpenForm "Erfassen Bulkchargen", acNormal, "", "", , acWindowNormal

Ist zwar Symptombekämpfung aber scheinbar hilfts...

Danke für die Hinweise und die Links.

Gruss JOG

[DF6GL]

Hallo,

Hast Du nun mal /decompile und/oder den Import in eine neue leere DB durchgeführt??

[database]

Hallo,

Ja die Berichte haben teilweise verschiedene Codes und Funktionen hinterlegt...

Es kann sein, dass du Codes einsetzt, die eine datenbezogen richtige Darstellung des Berichts verhindern,
die Art der 'Symptombekämpfung' läßt für mich auch diesen Schluß zu.

Code [Auswählen] Erweitern


DoCmd.OpenForm "Erfassen Bulkchargen", acDesign, "", "", , acWindowNormal
DoCmd.OpenForm "Erfassen Bulkchargen", acNormal, "", "", , acWindowNormal


Mit obigen Zeilen beförderst du das Formular in die Entwurfsansicht und danach wieder in die Normalansicht.
Hast du irgendwelche Codes 'Beim Anzeigen', 'Beim Laden' oder 'Beim Öffnen des Formulars im Einsatz, die sich auf
die Daten des zu öffnenden Berichts Einfluß nehmen?

Code [Auswählen] Erweitern

WHERE (((Bulkchargen.EtikettenDruck)=Yes));
oder

Code [Auswählen] Erweitern

WHERE (((Bulkchargen.EtikettenDruck)=True));
oder

Code [Auswählen] Erweitern

WHERE (((Bulkchargen.EtikettenDruck)<>0));
oder auch

Code [Auswählen] Erweitern

WHERE (((Bulkchargen.EtikettenDruck)=-1));

... wird keine Wirkung zeigen, wenn zum Zeitpunkt des Berichtsaufrufes das Tabellenfeld 'Bulkchargen.Etikettendruck' nicht oder noch nicht den gewünschten/erwarteten/aktualisierten Wert zeigt.
Setze mal einen Haltepunkt direkt vor den Berichtsaufruf und schau in die Tabelle ob die gewünschten DS mit Ja / True gekennzeichnet sind.

Eventuell kann dir dieses helfen:
http://www.donkarl.com?FAQ4.5

Was passiert den mit diesem Tabellenfeld nachdem der Druck durchgeführt wurde?

[JOG]

Hallo

Das ist mir soweit klar, dass ich mit der "Symptombekämpfung" das Formular lediglich zuerst in die Entwurfs- und danach wieder in die Normalansicht stelle und erst danach den Bericht auslöse.

Muss vielleicht noch sagen, dass es immer dann auftritt wenn ich neue Datensätze ins entsprechende frm eingebe.

Der Bericht enhält im übrigen folgende Prozedur als Code:

Beim Drucken:

Code [Auswählen] Erweitern

Private Sub Detailbereich_Print(Cancel As Integer, PrintCount As Integer)
   Dim AnzahlEtiketten As Long, I As Long, TypFeld As String, FarbeGrün As Long, FarbeRot As Long
   AnzahlEtiketten = 5
   FarbeRot = RGB(242, 30, 30)
   FarbeGrün = RGB(0, 184, 0)
   
       If AnzahlEtiketten = 0 Then
   ' Wenn Wert 0 ist, dann gar nichts drucken
       Me.NextRecord = True
       Me.MoveLayout = False
       Me.PrintSection = False
       
     Else
     ' Druckvorgang für diesen Datensatz wiederholen,
     ' wenn AnzahlEtiketten noch nicht erreicht ist
       End If
     
       If PrintCount < AnzahlEtiketten Then
           Me.NextRecord = False
       End If
       
       For I = 1 To AnzahlEtiketten
       Me.txtZusatz__txtMusterTyp = DLookup("Z_Text", "tblZusatz", "ZID=" & PrintCount Mod (AnzahlEtiketten + 1))
       
       Me.txtZusatz__txtMusterTyp.FontBold = True
       If Me.txtZusatz__txtMusterTyp = "Prüfmuster Anfang" Then
       Me.txtZusatz__txtMusterTyp.ForeColor = FarbeGrün
       ElseIf Me.txtZusatz__txtMusterTyp = "Prüfmuster Ende" Then
       Me.txtZusatz__txtMusterTyp.ForeColor = FarbeGrün
       Else: Me.txtZusatz__txtMusterTyp.ForeColor = FarbeRot
       End If
       
       Next I
       
      End Sub

In der Seitenansicht wird der Bericht stets korrekt angezeigt. Der Fehler zeigt sich effektiv erst, wenn ich aus der Seitenansicht Drucke (via Druckermenü).

Den Tip mit dem Import der DB in eine neue leere haben ich ebenfalls ausprobiert sowie auch den Befehl in Acces "DB komprimieren und reparieren". Hat leider auch nicht das gewünschte Ergebnis erbracht...

Gruss JOG

[bahasu]

Hi,

du legst fest:
AnzahlEtiketten = 5  

und fragst dann ab:
If AnzahlEtiketten = 0 Then

Welchen Sinn hat das?


Ginge nicht auch als vereinfachte Form (hier allerdings ohne die farblichen Zuweisungen):

Private Sub Detailbereich_Print(Cancel As Integer, PrintCount As Integer)
    'wenn AnzahlEtiketten ' noch nicht erreicht ist
    If Me.PrintCount < 5 Then
        Me.NextRecord = False
    End If
   
    Me.txtZusatz = Nz(DLookup("Z_Text", "tblZusatz", "ZID = " & Me.PrintCount), "")
End Sub

Bei meinem Test wurde auch ohne for next beim ersten Etikett "Prüfmuster Anfang" und beim letzten "Prüfmuster Ende" gedruckt.

Harald

[database]

Hallo,

...wenn ich neue Datensätze ins entsprechende frm eingebe

Hast du schon probiert, vor dem Bereichtsaufruf den DS zu wechseln - also den neuen DS zu verlassen und danach wieder zurückzukehren?
Wenn das funktioniert dann schau mal den Link in meiner letzten Antwort an.

[JOG]

Hallo zusammen

Ich glaub, dass ich mit dem Hinweis den DS zu wechseln am Ziel bin. Damit konnte ich auf jeden Fall den Fehler nicht mehr provozieren. Die anderen Hinweise behalte ich auf jeden Fall im Hinterkopf.

Vielen Dank für Eure fachkundige Hilfe.

Gruss JOG

[bahasu]

Hi,

ich komme noch mal auf Fragen von Peter zurück:
"Hast du irgendwelche Codes 'Beim Anzeigen', 'Beim Laden' oder 'Beim Öffnen des Formulars im Einsatz, die sich auf
die Daten des zu öffnenden Berichts Einfluß nehmen?"

Da Du schreibst, dass der Datensatzwechsel ausreicht, um die "Macke" zu vermeiden, betrachte ich "Beim Laden" und "Beim Öffnen" als im Moment nicht relevant.

Also:
1. Gibt es eine Sub zum Ereignis "Beim Anzeigen"
2. wenn ja: was steht da?

Harald