[Gelöst] [CC] OnAfterGetRecord vor OnPreDataItem ausgeführt?

Heute wende ich mich mal mit einem ganz kuriosen Fall an euch:

In einem ClassicReport (vergleichbar mit dem Report 204 Verkaufsangebot) wird in einem der RoundLoop untergeordneten DataItem etwas ausgegeben.
Jedoch soll diese Ausgabe nur ein einziges Mal pro Beleg geschehen.
(Die Ausgabe der Belegzeilen erfolgt sortiert nach Belegart, Belegnr., Art, Zeilennr.; mein DataItem soll beim Wechsel zu einer bestimmten Art etwas ausgeben.)
Daher habe ich eine Boolean-Variable , welche festhält, ob die Ausgabe bereits erfolgt ist.
Im CopyLoop - OnAfterGetRecord setze ich die Variable auf FALSE.
In meinem neuen DataItem (Integer) frage ich im OnPreDataItem die Variable ab und breche die Ausgabe mit CurrReport.BREAK ab, falls die Variable TRUE ist oder noch nicht erfolgen soll, da die nächste Belegzeile noch nicht die richtige Art aufweist.
Im OnAfterGetRecord des neuen DataItems setze ich die Variable auf TRUE.

Grundsätzlich funktioniert das Ganze auch wunderbar, jedoch tritt unter mir nicht bekannten Umständen das Phänomen auf, dass bei bestimmten Belegnummern (reproduzierbar) zuerst der OnAfterGetRecord-Trigger meines neuen DataItems ausgeführt wird, bzw. der OnPreDataItem-Trigger komplett ignoriert wird.
Das hat zur Folge, dass meine Ausgabe zu früh erfolgt und folglich (aufgrund der im OnAfterGetRecord gesetzten Variable) nicht mehr an der richtigen Stelle ausgegeben wird.

Meine Boolean-Variable wird bedingungslos in den genannten OnAfterGetRecord-Triggern auf FALSE bzw. TRUE gesetzt.
In dem genannten OnPreDataItem-Trigger wird die Variable nur abgefragt.

Hier einmal die DataItem-Struktur zur besseren Veranschaulichung:

Code:

Sales Header
  CopyLoop
    PageLoop
      DimensionLoop1
      Sales Line
      RoundLoop
        MeinIntegerDataItem
      [...]

Nun meine Frage(n):
- Kennt jemand dieses Phänomen?
- Wie lässt es sich lösen?

[Edit]
Datenbank: 5.00 SP1
Runtime: 2009 R2 Build 33194
Server: SQL 2012
[/Edit]

Du hast lange nichts mehr selbst gefragt

jedoch tritt unter mir nicht bekannten Umständen das Phänomen auf, dass bei bestimmten Belegnummern (reproduzierbar) zuerst der OnAfterGetRecord-Trigger meines neuen DataItems ausgeführt wird, bzw. der OnPreDataItem-Trigger komplett ignoriert wird.

Wie hast du das geprüft? Springt der Debugger dann gar nicht mehr in den OnPreDataItem-Trigger?

(Die Ausgabe der Belegzeilen erfolgt sortiert nach Belegart, Belegnr., Art, Zeilennr.; mein

Hallo Timo,

nur was mir aufgefallen ist.
Belegart, Belegnr., Art, Zeilennr. ist kein Standardschlüssel, richtig?

Belegnummern (reproduzierbar)

Ist etwas an diesen Belegnummern besonders/anders?

mfg,
winfy

Hallo,

da ich schon öfter Probleme mit den Standardreports hatte, habe ich diese etwas abgeändert. Die Tabellen werden auch alle per direktem Link angesprochen, und nicht mehr wie früher üblich über Integer (wird bei dir evtl. auf die falsche Zählvariable gefiltert).

Code:

Sales Header
  CopyLoop
    PageLoop
      DimensionLoop1
      Sales Line   // nur um die zur SalesLine gehörenden Records in anderen Tabellen zu verlinken
        MeinIntegerDataItem
        SalesLine2 // eigentliche Ausgabe Recordzeile an der Stelle, wo Sie in der Reihenfolge hin gehört

Gruß, Fiddi

Code:

Sales Header
  CopyLoop
    PageLoop
      DimensionLoop1
      Sales Line
      RoundLoop
        MeinIntegerDataItem
      [...]

Roundloop hat als DataItemLinkReference - Pageloop
und SalesLine als DataItemLinkReference Salesheader.

Ich bin mir jetzt auch nicht ganz sicher.
Ich glaube die dargestellte Einrückung der Dataitems entspricht hier mit dem "CurrReport.BREAK" nicht der von dir gewollten Ablauflogik.

EDIT:
Bei dem Report bekomme ich jedenfalls einen Knoten in den Kopf.

mfg
winfy

Zuletzt geändert von winfy am 25. Januar 2013 16:21, insgesamt 1-mal geändert.

Du hast lange nichts mehr selbst gefragt

Ich bin zwar schon mit vielen Wassern gewaschen worden, aber manchmal stehe ich auch wie Ochs vorm Berg.

jedoch tritt unter mir nicht bekannten Umständen das Phänomen auf, dass bei bestimmten Belegnummern (reproduzierbar) zuerst der OnAfterGetRecord-Trigger meines neuen DataItems ausgeführt wird, bzw. der OnPreDataItem-Trigger komplett ignoriert wird.

Wie hast du das geprüft? Springt der Debugger dann gar nicht mehr in den OnPreDataItem-Trigger?

Ich hatte extra an zahlreichen Stellen Breakpoints verteilt (auch mehrere innerhalb des besagten OnPreDateItem), doch die hatte er beim ersten Durchlauf einfach nicht angesprungen und ist stattdessen direkt in den OnAfterGetRecord gesprungen.

(Die Ausgabe der Belegzeilen erfolgt sortiert nach Belegart, Belegnr., Art, Zeilennr.; mein

Belegart, Belegnr., Art, Zeilennr. ist kein Standardschlüssel, richtig?

Richtig, dies ist ein spezieller Sortierschlüssel, welcher jedoch keine Auswirkungen auf das untergeordnete, eingerückte DataItem hat.

Belegnummern (reproduzierbar)

Ist etwas an diesen Belegnummern besonders/anders?

Nein, an den Belegnummern ist nichts besonderes. Sie stammen alle aus derselben Nummernserie für Angebote und haben das Schema VAN13DE-000123 (= 123. Verkaufs-Angebot im Jahr 2013 des deutschen Mandanten).

da ich schon öfter Probleme mit den Standardreports hatte, habe ich diese etwas abgeändert. Die Tabellen werden auch alle per direktem Link angesprochen, und nicht mehr wie früher üblich über Integer (wird bei dir evtl. auf die falsche Zählvariable gefiltert).

Danke für den Hinweis, jedoch ist das untergeordnete, eingerückte DataItem nicht mit einem anderen DataItem verlinkt, sondern wird pro RoundLoop immer einmal angesprungen.
Im OnPreDataItem erfolgt dann die Prüfung, ob jetzt der Zeitpunkt gekommen ist, die Section auszugeben.

Roundloop hat als DataItemLinkReference - Pageloop
und SalesLine als DataItemLinkReference Salesheader.

Ich glaube da bringt dir die Vorsortierung auf die "Art" nichts, oder?
Ich bin mir jetzt auch nicht ganz sicher, ich glaube die dargestellte Einrückung der Dataitems entspricht dann hier nicht der von dir gewollten Ablauflogik.

Das ist kein Problem, denn die Zeilen werden innerhalb der RoundLoop verarbeitet.
Wir haben vor der Verarbeitung einfach die Sortierung geändert, so dass sie so durchlaufen werden, wie wir sie brauchen.
Das funktioniert auch einwandfrei.


Nachdem ich eine gefühlte Ewigkeit debuggt habe, ist mir zu meiner großen Freude dann natürlich auch der Client abgestürzt.
Na Klasse, so macht die Arbeit Spaß.
NAV neu gestartet, Breakpoints fleißig verteilt, Debugger an und alles nochmal von vorne.
Und siehe da: Plötzlich springt er wieder artig in den OnPreDataItem-Trigger.

Fazit: Der Client hatte einfach nur einen "Schluckauf" und musste nur neu gestartet werden.

Ich danke trotzdem allen, die sich die Mühe gemacht haben, mögliche Ursachen für dieses seltsame Verhalten zu finden.

NAV neu gestartet, Breakpoints fleißig verteilt, Debugger an und alles nochmal von vorne.
Und siehe da: Plötzlich springt er wieder artig in den OnPreDataItem-Trigger.

Fazit: Der Client hatte einfach nur einen "Schluckauf" und musste nur neu gestartet werden.

Ich kannte das bisher nur anders herum: NAV verhielt sich beim Testen anders als das, was per Code hätte passieren sollen.
Erst nach dem Debuggen !! funktionierte es dann plötzlich ...

Das ist kein Problem, denn die Zeilen werden innerhalb der RoundLoop verarbeitet.
Wir haben vor der Verarbeitung einfach die Sortierung geändert, so dass sie so durchlaufen werden, wie wir sie brauchen.
Das funktioniert auch einwandfrei.

Du hast Recht ich hab mir den Report nicht ausgiebig genug angeschaut.
Im RoundLoop durchläuft er ja noch alle SalesLines. Wozu braucht der Report dann eigentlich das DataItem "Sales Line"?

Na egal, bei dem Report bekomme ich ohnehin einen Knoten im Kopf.

mfg,
winfy

Na egal, bei dem Report bekomme ich ohnehin einen Knoten im Kopf.

nicht nur du

Gruß, fiddi

Im RoundLoop durchläuft er ja noch alle SalesLines. Wozu braucht der Report dann eigentlich das DataItem "Sales Line"?

Om CopyLoop wird die temporäre (!) Variable SalesLine aufgebaut (*), um dann in DataItem RoundLoop abgerufen zu werden.
"Sales Line" wurde meines Erachtens nach nur dafür angelegt, um eine globale Variable namens "Sales Line" zu haben (wahrscheinlich historisch gewachsen).
Diese wird wiederum in RoundLoop verwendet:
SalesLine beinhaltet die tatsächlichen Daten,
"Sales Line" die anzudruckenden Daten in den Sections, die sich von SalesLine im Detail unterscheiden können (z.B. Kontonummer leer).

(*) Tolle Sache - wenn man hier die nummerischen Parameter austauscht, wird der Bericht nicht auf Basis der "Menge", sondern z.B. "Menge zu liefern" berechnet inkl. aller Summen und Steuern.

Hallo Natalie,

danke für die detaillierte Analyse.

mfg,
winfy