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".
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
10 | |
7 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 | |
4 |