Events werden IMMER durchlaufen?

Hallo zusammen,

gibt es eine Möglichkeit codetechnisch das Durchlaufen von Events zu vermeiden. (Analog z.B. einem DELETE(FALSE) vs. DELETE(TRUE)).
Die grundsätzliche Möglichkeit der Deatkvierung ist mir bewusst.

VG

ich sage einfach mal frech "nö" (mir ist kein Weg bekannt)

Warum willst du manche Events nicht durchlaufen?

Herzlich Willkommen bei uns!

gibt es eine Möglichkeit codetechnisch das Durchlaufen von Events zu vermeiden. (Analog z.B. einem DELETE(FALSE) vs. DELETE(TRUE)).
Die grundsätzliche Möglichkeit der Deatkvierung ist mir bewusst.

Wenn es dir wirklich darauf ankommt, dass Events erst gar nicht gefeuert werden:
die Codeunit, in welcher dein Subcriber definiert ist, auf EventSubscriberInstance = Manual stellen. Per Code zum passenden Zeitpunkt mittels BINDSUBSCRIPTION die Codeunit wieder "zum Leben erwecken".

Ansonsten, wenn der Event generell/automatisch gefeuert wird/werden soll, kannst du über die Subscriber-Parameter einiges herauslesen. So kannst du bei einem Tabellen-Delete herauslesen, ob das Event mit DELETE(FALSE) oder DELETE(TRUE) gefeuert worden war, und ggf. die weitere Ausführung des Events mit EXIT verlassen.

Der konkrete Hintergrund war, dass ich eine temporäre Instanz der Customer Tabelle hatte und in meiner Routine irgendwann ein Delete darauf gemacht habe.
Sinn und Zweck sei jetzt mal dahingestellt. Aber dies hat dazu geführt, dass die Events durchlaufen wurden. Das wollte ich natürlich nicht.
Ich wollte nur die Customer Tabellenstruktur temporäre nutzen und durch das Delete sicherstellen, dass nach der Verarbeitung die temporäre Instanz leer ist (-> Was eine Plausiblisierung dafür ist, dass die Verarbeitung alles berücksichtigt hat)

Das ist jetzt nur ein Beispiel. Ich kann mir jedoch vorstellen, dass es weitere Szenarien gibt, in welchen das ein Problem sein könnte.

Der konkrete Hintergrund war, dass ich eine temporäre Instanz der Customer Tabelle hatte und in meiner Routine irgendwann ein Delete darauf gemacht habe.
Sinn und Zweck sei jetzt mal dahingestellt. Aber dies hat dazu geführt, dass die Events durchlaufen wurden. Das wollte ich natürlich nicht.

Code:

IF Rec.ISTEMPORARY THEN
  EXIT;

Sowas gehört in (fast) alle Subscribers.

IF Rec.ISTEMPORARY THEN
EXIT;

-> Das sieht der Standard scheinbar gar nicht so :).

In den betroffenen Codeunits 1520, 1535, 1550 und 9150 gibt es eine Funktion die das so macht....

ah, dein Beispiel ist genial...soweit habe ich natürlich nicht gedacht.

also ich bleibe dabei - nein es geht nicht - außer du hast die notwendigen Zugriffsrechte in den Objekten, welche die Events-Subscriben, um dort dann die ausführung der Funktionen bei bestimmten Situationen auszuschalten.
Im Grunde geht es ja nicht darum, die Events nicht abzufeuern, sondern die Subscriber temporär an der Codeausführung zu hindern

Wenn du dann natürlich die EventSubscriber anpasst, ist die ganze Idee der Events aus meiner Sicht wieder futsch.

Ich denke halt nur, dass dies bzgl. Events mit Sicherheit für bestimmte Szenarien einfach nicht durchdacht ist.
Ist für mich auch eine wichtige Erkenntniss im Umgang mit Events.

Aufgefallen ist mir dies im Endeffekt nur wegen Performance Problemen. Bei dem konkret geschilderten Fall ging es um eine Routine, welche für die Customer Tabelle interne individuelle Felder füllt.
Betroffen waren in etwa 700.000 Datensätze. Ohne die Subscriber Geschichten war das Laufzeitverhalten um den Faktor 20 schneller. Die über die Events angesprochenen Tabellen sind dabei natürlich leer gewesen!

VG

Das sieht der Standard scheinbar gar nicht so :).

Tut er schon, nur sind auch Programmierer bei Microsoft Menschen, und Menschen machen Fehler ... Und es wird so lange nicht korrigiert, bis das jemand meldet ....

Stimmt, wenn man bei einem kleinen Ausschnitt (C1520, C1535, C9150) von Event Funktionen - mit gefühlten 200 Funktionen - bei einer Funktion diesen architekturspezifischen Grundsatz im Standard (NAV 2017, CU6) vorfindet, dann kann man behaupten das er das schon tut ;)...

Ich bin auf jeden Fall bzgl. Events schlauer geworden, besten Dank dafür. Ich halte diese auch für einen Grundsatz eines modernen Frameworks. Es kann nur besser werden und das wird es auch :)

VG