Hallo svit,
es gibt für alles eine Lösung auch für dein Problem mit den Programmtriggern. Zumindest hab ich für mich eine Lösung gefunden.
Ich nenne das "indirektes Triggern" und funktioniert wenn man einige Dinge beachtet einwandfrei.

Im Prinzip geht das so.

  • Es gibt nur ein einheitliches Programm für die Verarbeitung von Triggern. Dieses Programm dient als "Middleware", und löst damit das Problem des exlusiven Zugriffes bei Änderungen am Trigger. Da diesen nun die Middelware besitzt. Damit läßt sich der Trigger "an" und "aus"schalten. Mehr dazu später...

  • Das Middlewareprogramm, das als Triggerprogramm an die physische Datei als angehängt ist, ermittelt aus der übergebenen Triggerstruktur den Dateinamen und die LIB der Physische Datei.

  • mit diesen Werten wird dann ein gleichlautender Datenbereich geladen der das eigentliche Verhalten steuert (.. also *LIB/PFDateiname ==> *LIB/DTAARADateiname Inhalt in der Form "{1|0}{LIB}{PGM}


  • {0|1} steuert ob der Trigger überhaupt aufgerufen wird
  • {LIB} Bibliothek
  • {PGM}Programmname
  • an dieses Programm wird die komplette PF-Triggerdatenstruktur als Parameter übergeben. In diesem Prog kannst Du dann machen was Du willst. Das Programm läßt sich dadurch jederzeit An- und Abschalten oder auch Verändern und an neue Erfordernisse anpassen, ohne das Du das System exlusiv benötigst. Einfach TriggerDatenberisch auf "0", und das war's. Natürlich ist der eigentliche Trigger noch aktiv, aber er tut nichts mehr.

  • Ich habe diese Vorgehensweise dann auch noch mit einer Datenwarteschlange gekoppelt. Ich verliere damit keine "Events" während mein Trigger "deaktiviert" ist.


Das System läuft "LIVE" auf mehreren ERP Systemen bei Kunden, die teilweise pro Tag 2Mio Transaktionen haben.

schönen Abend noch
FX