Question

Views that do not have ROWVERSION

J
Rank
Userlevel 3
Badge +9

For Data Warehouse use, we are looking to use a large number of IFS views and with these views, we would want only incremental changes.

Now and for some views, there is ROWVERSION (time / date stamp) which is fine but on some of the views, the ROWVERSION is just a number (not unique) and on some views, ROWVERSION does not exist or with no available columns that could be used to identify incremental changes. 

Is anybody aware of any method or mechanism that could be used in a consistent way across ‘all’ IFS views that could be used to identify  incremental changes?

Any help / assistances would be greatly appreciated. 

  

4 replies

S
Rank
Userlevel 6
Badge +12

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

Just because something is part of a plan doesn't make it right.
J
Rank
Userlevel 3
Badge +9

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. 

S
Rank
Userlevel 6
Badge +12

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

Just because something is part of a plan doesn't make it right.
T
Rank
Userlevel 4
Badge +11

@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.

Reply


Terms & ConditionsCookie settings