Could you utilize the history tracking for this? It sounds like that would be exactly what you want, and you can decide down to the field level the changes to track/log.

Thanks,

Joe Kaufman

Thank you and we did look at this but as the views are highly transactable, we thought turning on history tracking wouldn’t be the good option due to system overhead / etc. 

Understandable, but if certain LUs simply do not have the timestamps you need, you’d have to create custom fields to house that (driven by custom events, I imagine). So, you’d be “rolling your own” audit trail system that would likely be just as performance-intensive as the IFS-native history tracking.

And if at the end of the day you want to know what has changed, I am not sure I understand how timestamps are going to get you fully where you want to be. Don’t you want to see what actually changed? The history tracking would give you that.

Could you mock up transactional volume in a TEST environment that mimics production, then turn on history to see how it performs? The back-end might surprise you on how well it does, as (I believe) the history is logged with deferred, asynchronous triggers that might not affect foreground processes as much as you think (depending on DBMS resources).

Thanks,

Joe Kaufman

@JamesW72 

For incremental changes, you need new rowkeys and rowkeys with new rowversions.  It doesn’t matter if it’s a number or date. 

If a view doesn’t have rowversion available, then you’d see if you actually need a rowversion (maybe new rowkeys are created?) or you’d look for a comparable view that does have the rowversion, or you’d make up the rowversion from an available date. 

For views without a lot of records, like basic data, you could elect to do a full refresh instead.