When multiple users try to update a single record at the same time, you will have concurrency issues. In a single-tier application, this is never an issue because there is only one user accessing data. In a two-tier system, you as the developer have the option of implementing either pessimistic or optimistic locking—however, this depends on the Relational Database Management System (RDBMS) because not all databases support optimistic locking. In most two-tier applications, you are always connected to the database when you are reading and writing data. If you set up pessimistic concurrency, when one user is trying to update a record, no other user can update the record at the same time (they will receive an error message explaining that the record is locked). If you implement optimistic concurrency, you will have to write code to handle the occurrence of one user updating a record that is not current. In a three-tier application, the developer must always handle database updates because no connection is maintained with the database. In most cases, this applies to a well-written two-tier application as well.

Microsoft’s new database access technology, ADO.NET, can help to make many of these issues easier to solve—but even ADO.NET will only throw an exception saying that someone else has updated the record. It is still up to the developer to handle this situation, and it is rarely solved the same way on any two applications. How you handle this situation depends mostly on what the users want.