This issue is commonly called Data Concurrency, concurrency control, or simply Concurrency.
It IS a big deal, and the probability is VERY HIGH in a multi-user environment that "collision" will occur, and often. An enterprise system that does not consider and mitigate concurrency issues would not be considered professional. I have never worked on an enterprise app that didn't deal with concurrency in a more or less robust manner, and have seen lots of various solutions. No matter what anyone tells you, in a real enterprise environment this is a critical issue that must be considered and dealt with.
There are several ways to deal with this. The basic requirement is to be able to determine if the data in the row you are editing has changed since you last read it. There are at least 4 common ways to do this.
1 - The data from the row is stored locally in its original form until the attempt is made to update the data. At that time, the row is retrieved from the database and the current values are compared with the original data. If they are the same, then you can go ahead and make the Update. If they are different, you can handle it based on some rule that you follow - the typical one being to let the user know that the data has been changed by another user and their save didn't go through. Sometimes it is appropriate to allow them to have their change override the original change. You have to decide what rules best fit the application you are writing. The stored original data can be in the form of XML, discrete variables, or whatever works for you. It can be stored in session, or part of a hidden field in the html.
2 - Add a datetime stamp field to every table. That field holds the datetime stamp of when the field was last updated. You always retrieve this field when reading data and keep it for checking when you return to do your save. If the stamp is different, you handle it in the same way as option 1. Again, the datetime stamp can be stored in session, or part of a hidden field in the html - this goes for the remaining options as well.
3 - Add a guid that does the same thing as the timestamp verion - it acts as a value that is changed each time the data in the row is changed and can be checked to see if the read you are working with has the same guid that is currently in the database.
4 - "Hash" the data in the row you are working with using some simple (and hopefully very fast) algorithm. You store the hash number and then, like the other options, retrieve and rehash the data - if the hashed values are the same, then proceed, and if different, inform the user like the other options. This method is useful when you aren't given the option of adding fields to the tables as in option 2 and 3.
There are other ways as well, but they mostly fall into the above pattern. You can look up things like DiffGrams or concurrency control on the interent to find a starting point for gathering more info. For example, here is a link that came up when I search on concurrency control:
http://www.agiledata.org/essays/concurrencyControl.html
I almost always use the first option. In a typical client/server or n-tier windows app it is very simple to serialize the original data, and it gives you the benefit of checking what data actually changed so you could inform the user if that is useful for your user.
When you have a lot of data - such as huge text fields, then the hashing or datetime stamp or guid methods can be better so you don't have to pass around or store all sorts of data.
There are numerous other variations to consider. In some cases you might allow changes to fields that have not been changed. For example, in this scheme: If the other user has changed the LastName field, but not the FirstName field, and your user is changing the FirstName field but not the LastName field, you would allow that second change to go through.
A note: I am a bit surprised at how, in the past, little information has been out on the internet about dealing with this issue. Lately, there seems to be more out there that you can track down. This is such a fundamental issue, and as far as I am concerned is on a par with transactions in being something that enterprise programmers must know about.
One last thing:
The flags idea is a difficult solution to implement well for the concurrency problem, but it shows you are thinking. This sort of locking will be troublesome to deal with. I've worked on several projects where this sort of thing had been implemented to solve various locking needs and caused endless bugs and a poor user experience. It can be done, but it isn't hardly worth the effort unless there is no other solution.
Woody Z
http://www.learntoprogramnow.com