Multiuser Updates
In the previous section, you read data from the database into a dataset, updated the data in the dataset, and then wrote the changes back to the database. It is possible, of course, that many other people were simultaneously reading the same data into datasets of their own, editing their data, and writing their changes back to the database.
You can easily imagine that this could cause tremendous problems of data corruption. Imagine, for example, that a QA person downloads the current open bugs and begins to review the bugs with an eye towards updating some of the information. Meanwhile, across the office (or across town) a developer has read a few open bugs into a form of his own. It happens that they both are reading bug 17, which looks like this:
BugID 17 Reporter: John Galt Severity: High Status: Assigned Owner: Jesse Liberty
The QA person decides to change the Severity to Medium and to reassign the bug to Dan Hurwitz. Meanwhile the developer is updating his dataset to change the action taken on the bug. The QA person writes back his changes, and the database now thinks the Owner is Dan and the Severity is Medium. The record now appears as follows:
BugID 17 Reporter: John Galt Severity: Medium Status: Assigned Owner: Dan Hurwitz
Then the developer writes back his dataset, in which the Owner was
Jesse and the Severity was High. These earlier values are written
over the values updated by QA, and the QA edits are lost. The
technical term for this is bad
.
To prevent ...
Get Programming ASP .NET now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.