http://msdn.microsoft.com/en-us/library/ms182776.aspx
"You can use the rowversion column of a row to easily determine whether any value in the row has changed since the last time it was read. If any change is made to the row, the rowversion value is updated. If no change is made to the row, the rowversion value is the same as when it was previously read. To return the current rowversion value for a database, use @@DBTS."
So what? Rowversion allows you to use more intelligent methods to choose which data to send to a user. This is a very good thing in that it enables you to reduce the amount of data retrieved from the database (good) and sent over the wire (great!).
Contrived example: suppose you have two users simultaneously using a sales application, adding line items for the same large order. It would be nice if each user could see the changes the other had made without needing to reload the order. In order to accomplish the goal of having up to date data without interrupting the user experience, the client end of the sales system should occasionally request updates. If the max rowversion in the client for the selected order is less than the server's max rowversion for the selected order, you know that the server has data that hasn't made it to the client yet. The best part is you also know which records are new or modified! You only need to send the records with updates to the client, which leads to a much nicer experience for everyone.
That's all fine for updates and inserts, but what about deletes? Suppose User A deletes line 17 that User B had originally entered. If you delete a row, you also delete its rowversion entry, so User B will have to reload the order to see that change. That is not optimal. You can avoid situations like this with the addition of another column in your table, which you might name "IsActive". If you had that column, you could set "IsActive" to false which would update the rowversion and User B could see that the row was deleted the next time his/her client got new data for the order.
"You can use the rowversion column of a row to easily determine whether any value in the row has changed since the last time it was read. If any change is made to the row, the rowversion value is updated. If no change is made to the row, the rowversion value is the same as when it was previously read. To return the current rowversion value for a database, use @@DBTS."
So what? Rowversion allows you to use more intelligent methods to choose which data to send to a user. This is a very good thing in that it enables you to reduce the amount of data retrieved from the database (good) and sent over the wire (great!).
Contrived example: suppose you have two users simultaneously using a sales application, adding line items for the same large order. It would be nice if each user could see the changes the other had made without needing to reload the order. In order to accomplish the goal of having up to date data without interrupting the user experience, the client end of the sales system should occasionally request updates. If the max rowversion in the client for the selected order is less than the server's max rowversion for the selected order, you know that the server has data that hasn't made it to the client yet. The best part is you also know which records are new or modified! You only need to send the records with updates to the client, which leads to a much nicer experience for everyone.
That's all fine for updates and inserts, but what about deletes? Suppose User A deletes line 17 that User B had originally entered. If you delete a row, you also delete its rowversion entry, so User B will have to reload the order to see that change. That is not optimal. You can avoid situations like this with the addition of another column in your table, which you might name "IsActive". If you had that column, you could set "IsActive" to false which would update the rowversion and User B could see that the row was deleted the next time his/her client got new data for the order.
