Lastly we will look at some activity diagrams for updating a recordset in the database. If you cast your mind back to Chapter 6 you may recall that our interview with Valerie, the Northwind Sales Representative, highlighted a problem with the old order processing system - if another user was accessing the database table that Valerie wanted to use, she was simply prevented from having access to it until the other user had finished with it. With our ADO disconnected recordsets we have overcome this problem. Each user can work with a recordset on the client machine. The user can then request to update the database. MTS also allows us to perform our database updates under transactions. During this process the system must check for any conflicting records (another user may have been making conflicting changes to the same data), attempt to reconcile any differences then either accept the transaction or rollback the changes. This is not a straightforward process and we will not explore it in all its gory detail. Let's have a look at an activity diagram describing a generic UpdateRecordset method:
If the transaction was successful we call SetComplete, and the changes will be committed. If for any reason an error occurred (such as conflicting records being found) then we need to call SetAbort and all changes will be rolled back:
Of course, the Reconcile step is a whole complicated activity diagram on its own. Also the steps that would occur when determining the type of recordset and preparing to send it back would be the focus of yet another activity diagram. As I said, not a simple process.
Was this article helpful?