Note: a glossary of technical terms used in these articles can be found on the Web sites of the authors. The URLs are and We are about to split an episode. The user knows nothing of this - all the user knows is what the database tells us right now and what changes he/she wants to make to the database. With his/her delete transaction, as shown in Figure 1, the user is telling us, first of all, that she believes that the database currently asserts that P861 was in effect from 4/01/08 to 8/01/08. If that turns out not to be true, then the asserted versioning framework will reject his/her transaction. Next, the user is also telling us that he/she believes that P861 was not in effect during that time. The user now believes, in other words, that the correction made a month ago was a mistake. So he/she is submitting a transaction to return the database to its pre-3/01/09 assertion about P861, namely that it was in effect from January to April of last year, and from August of last year going forward, but it was not in effect from April to August. Figure 1 shows us the Policy table after the delete transaction has been applied. 

As with any original delete transaction, the first thing that must be done is to withdraw the affected versions of the designated object from current assertion time. In this case, there is only one such assertion. It is the one made with row 3. Last month, row 3 began asserting that policy P861 was in effect from January to August of last year. We now believe (once again) that the assertion made by row 3 is incorrect, and so we withdraw it. We do this by overwriting the assertion end date of 9999 in row 3 with the current date, April 1, 2009. The second temporal transaction creates the replacement assertion. That replacement is row 5; and starting in April of this year, it claims that policy P861 was in effect from January to April of last year – not from January to August. After both the physical update and the physical insert are completed, the original transaction is complete. Locks are released on the affected data and its isolation ends. It is now a visible part of the database.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access