Thanks to all for the many suggestions. To answer a few questions that
came up and provide a bit more information.
This is an application that is mostly stored procedure calls through ODBC
using a common IBM i user profile. In each (most) of those stored
procedures, we write a change log. Information in the change log includes
real user, application, action, key info, changed column, old value, and
new value. This information is used to review changes as well as an undo
function in parts of our application.
We were considering using triggers to capture the changes instead of
manually writing the changes since it would also capture changes outside
our application and more easily capture "mass update" changes, i.e. an SQL
update that affects multiple rows. Since a trigger program would not have
much of the info we want to log we would need a way to pass that info in.
If something outside our application is making the change we would go off
call stack and job information to get what we can. Because the trigger
could be called multiple times across multiple files during one
"transaction" this extra information would have to be available for that
entire time.
To summarize the current suggestions:
- environment variables using setenv and getenv
- a service program with set and get procedures specific to this info
- add a unique id column to the original tables and use another table
with that unique id and the info
- a data area
- a data queue
- a user index
Brian
Original post:
I would like to be able to provide additional information that is not
available in the trigger buffer.
This additional information would be set by application programs and
used in the trigger program to create a log of changes for the application.
I have considered a table, a data area, and an SQL global variable.
Are there other options? Which option would provide the best
performance?
midrange.com
