Re: Passing Info to a trigger program

An alternative to triggers and log files might be journaling the file.
Granted, analyzing the data is trickier but can be improved by mapping the
data field into an external data structure.

Another alternative to triggers and log files might be using temporal
tables. This is a really cool feature which came out in 7.3. If you're
not opposed to changing the underlying table it's easy to add columns which
will default to job attributes, etc. For example, the IP address of the
client who changed this row.
https://www.ibm.com/docs/en/i/7.5?topic=administration-working-system-period-temporal-tables

I could send you a power point I used at a presentation years ago. In the
example I used I modified an InforLX table to make it a temporal table. I
added additional columns, etc. Since Infor doesn't access the table itself
but uses LF's not a single program needed to be recompiled.

On Thu, Aug 3, 2023 at 8:03 AM Brian Garland via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

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?

--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or company to whom they are
addressed.
Do not disclose, distribute, or copy this email to others outside your
company. If you have received this email in error, please notify the
sender
immediately and delete this email from your system.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.