A few suggstions:
- You could write a value to the database from the appserver call and pick that up in the trigger
- You can publish a "getValue" from the trigger and let the AppServer call "subscribe" to it
- You can use a singleton procedure thats started with the session that holds variables for you
- You could use a super-procedure to store the values, but I would prefer a singleton instead
So multiple options to get the job done.
1. Use a Static property in a class.
2. Don't use a trigger.
Thanks for the suggestions.
I ended up with using a property in a class.
I didn't know that the session in the database trigger was the same as the session of the appserver-procedure.
It is important to know the cause for which you want to use the value in the trigger, regardless of whether it is the app server or a normal procedure, the trigger inherits attributes of the previous procedure, these will be available as long as you prepare them properly.
Ordinarily a value should not be used in the database trigger, since its objective is only processes on the record.
If you still want to use a value in the trigger and inherit it from the call of the local procedure or app server, you can use a shared variable, it is not the most elegant method but it works.
The disadvantage is that at compile time you should always load the definition of this variable into memory and ensure that it is created at run time.
Reason is logging if some fields are changed.
The application has his own user table, not defined as database-users. The info of the userid is passed to the appserver, and in the database-trigger we need to create a log-record and save userid, datetime and old- new value.
I understand, as control fields or bitacoras.
The case you describe is very simple if you use shared variables.
In the main process declare a new shared variable and in the trigger you use it only.
define new shared var vsIdUser as char.
vdsIdUser = "blablabla".
define shared var vsIdUser as char.
table.idUser = vsIdUser.