What Happens After My Update Attempt?

[Previous] [Next]

If the attempt to update your database is successful, the ADO Cursor Engine takes some simple steps to try to let you update that same record again with your same Recordset object. Remember that in our example, the ADO Cursor Engine built and submitted the following query to the database:

 UPDATE Customers SET BalanceDue = 175 WHERE CustomerID = 7 AND BalanceDue = 125 

Suppose that the update attempt succeeds and you want to modify that same record of data in your database again without reexecuting your initial query. For example, the customer places a second order worth $80 while on the phone with the operator who's using your application. Ultimately, you want the ADO Cursor Engine to generate and submit the following query:

 UPDATE Customers SET BalanceDue = 255 WHERE CustomerID = 7 AND BalanceDue = 175 

In short, you want the ADO Cursor Engine to store the data it uses to successfully update the record in your table so that it can use that data during future update attempts. It's no coincidence that this is exactly what happens. When your update succeeds, the ADO Cursor Engine will change the OriginalValue property on the Field objects that you modified to reflect the change made to the record in your database.

NOTE

---

The fact that the value of the OriginalValue property changes when you update your database means that the name of the OriginalValue property was a bit of a misnomer. However, this value makes it possible (in most cases) to modify the same record in your Recordset object multiple times without having to refetch the current contents of the record from your database. In Chapter 11, we'll examine some cases in which this repeated modification isn't possible.

Your update attempt might fail for several reasons. When an update attempt fails because another user has modified the same record, it's considered an optimistic updating conflict. Chapter 12 will cover this type of problem in more detail.

Update attempts that fail because of unacceptable data, violations of primary or foreign key constraints, and so on are not considered conflicts because they technically are not failures caused by another user modifying the same record. I recommend that, while designing your application, you intentionally cause such a violation. Then find a way to trap for the problems you expect and resolve them accordingly.