Den POST_QUERY Trigger zähmen oder wie verändere ich Datensätze, ohne dass es Forms merkt

Im aktuellen Projekt kam wieder einmal die Situation auf, dass ein Bereich einer Forms Maske Daten anzeigt, die einerseits Non-Basetable-Items sind und nicht direkt in der Query gefüllt werden.

Dafür bietet sich natürlich der POST_QUERY Trigger an, der dann diese Felder mit Daten füllt. Kleiner Nachteil der Methode, der Record-Status wird verändert und ein erneutes Abfragen der Daten führt zu der berühmten Frage:

Ok kein Problem, dafür gibt es einen guten Workaround. Einfach wieder nach dem Füllen der Daten den Record-Status auf QUERY setzen.

set_record_property(:system.trigger_record, 'block_name', status, query_status);

Und nun kommt der komplexere Weg, ich möchte Daten verändern, die Basetable-Items sind und schon in der eigentlichen Query gefüllt. Da kommt die nächste Feinheit, die Daten sind nämlich gesperrt zur weiteren Bearbeitung, falls der Locking-Modus auf Immediate steht.

Als mögliches Fehlerbild ergibt sich dann sowas z.B.

Fehlermeldung auf der Datenbank, dass der Datensatz gesperrt ist

Und das obwohl die Daten sogar per Programmcode gelöscht und neu abgerufen worden sind in Forms durch ein CLEAR_BLOCK und ein EXECUTE_QUERY.

Die Lösung des Dilemmas erfolgt durch Veränderung des Locking-Modus im POST_QUERY:

Set_Block_Property ('block_name', LOCKING_MODE, Delayed);

   Wert der Basetable-Items verändern z.B. durch ein SELECT INTO...

Set_Block_Property ('block_name', LOCKING_MODE, Immediate);
set_record_property(:system.trigger_record, 'block_name', status, query_status);

Was heißt das nun?

Es werden oftmals in Forms durch einen POST_QUERY Trigger Daten in anderen Feldern verändert, die ohne die obige Sonderbehandlung dann möglichweise zu einem komischen Verhalten führen kann. Aber durch geschickte Befehle kann so getan werden, als merke Forms die nachträglichen Zuweisungen nicht.

Viel Spaß beim Ausprobieren
Holger