Checking If Form Data Is Stale Before Saving

Monday, June 13, 2005

With multiple users working on the same database using ASP.NET webforms, you have to make a design decision how to prevent stale data from being saved. By definition in a web application the data you see in a form is a snapshot in time, so when you post your changes back to the server, the save method must check to see if the data you worked on is stale, meaning it has been changed by another user in the meantime.
public void Form_OnSave() {
  if (DataIsStale()) {
    if (!WarnContinue("The data is stale, mate!"))


MEANING: The currently shown data has a RevisionNumber that is older than the data currently in database

MEANING: The RevisionNumber is the id of the last HistoryItem of an "updated"-class type (created, changed, deleted, deactivated)


MEANING: A record in a table called History with columns: history item id, date, user id, guid of element, historytype (created, viewed, changed, deactivated, deleted, etc), session id (only in Method B)

Method A

When saving an element the RevisionNumbers are compared
UPSIDE: Simple and easy solution
DOWNSIDE: You need to store the revision number in the form

Method B

The current SessionID is saved alongside the HistoryItem, so the date of the last HistoryItem of the viewed type and for the current SessionID is compared to the date of the last HistoryItem of an "updated"-class type for all other session ids.
UPSIDE: Doesn't require any extra fields added to the form
DOWNSIDE: The session id is the same when a user has more windows open so it will not alarm a user that edits the same element in two browser windows and saves them both.

Method C

All the original data is compared to the current data in database, if different the the two objects must be different revisions, hence data is stale.
UPSIDE: You don't need HistoryItems and RevisionNumbers and SessionIDs
DOWNSIDE: All the orignal values must also be stored in the form


Post a Comment

<< Home