Skip to Content

Another misunderstanding of mine has been clarified over the last few days, so I thought I would share it with this forum, hopefully it is helpful. The question was around the delta and how this function works in a To IdS pass.

The first time the delta is performed for a record, the values of the attributes that are read from the source for the active attributes in the Destination are hashed and the result stored in the “delta table”.

Delta Picture.jpg

In my case, that is the records in black above.

The next time the delta runs, the data in the source table for these attributes is again hashed and compared against the “delta table”. If the hash is found, then no change has taken place and no update is made to the IdS.

There are 2 circumstances in which the hash can change, the first is the obvious one of when the data changes, the second is when the attributes that are active in the pass are changed, so in the case above, if we disabled MX_DEPARTMENT. In this scenario, every record read would be flagged as modified as the hash would be different – this time it contains no MX_DEPARTMENT.

So if that’s clear, the only thing left to clarify is why I write “delta table” – that is because the delta table is often looked at as a combination of logentries and delta_defs tables and not a single table in their own right.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Arun kumar Akuthota

    The Delta tab is more for updating the log entries with the new values and updates after that. System use numbering system for each change like 1 for no changes and first time entry and then 2 and 3 are for modifications and 4&5 for deletions then it would be changed to 6 which means the deletion happened. The deletion is when the source is not having the record.

    I saw many times the deletion does not happen accurately if we chose automatic deletions. 

    (0) 

Leave a Reply