With respect to IBM's document "A Matter of Time: Temporal Data Management in DB2 for z/OS":
To have a clear understanding of IBM's PIT (bitemporal) implementation, could you please provide the values of "TRANS_START" for the example provided.
Now, if the change described (On March 1, 2012, someone changed the terms of Policy 1111 effective June 1, 2012...) results in "TRANS_START" value being equal to "SYS_START" for all rows, I won't know what the intended purpose of "TRANS_START". If that is the case, please execute a business transaction where "TRANS_START" differs?
Thanks in advance!
This topic has been locked.
1 reply Latest Post - 2012-05-05T01:01:42Z by MatthiasNicola
Pinned topic Bitemporal use of TRANS_START
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-05-05T01:01:42Z at 2012-05-05T01:01:42Z by MatthiasNicola
MatthiasNicola 120000E28R7 PostsACCEPTED ANSWER
Re: Bitemporal use of TRANS_START2012-05-05T01:01:42Z in response to JPA5Hi,
the core of your question is really about when the transaction start id ("trans_start") column might have a value that is different from the "system_start" column.
When applications issue concurrent operations on a system-period temporal table, two concurrent transactions might modify the same row. Concurrent modifications of the same row can potentially lead to inconsistent history rows in which system_start might be greater than system_end.
In such a situation, DB2 10 for Linux, UNIX, Windows can either rollback one of the transactions, or adjust the system_start value which would then differ from trans_start.
For further information on this topic, see:
or the section "Choose between system-time adjustments and rollbacks" in this article: