-
Include Only the Primary Key Columns , last in win
-
Include the Primary Key and Timestamp Columns?( Recommended )
?4. ?? Include the Primary Key Columns and Modified Columns
Include Only the Primary Key Columns
“last in wins”
Here’s a quick breakdown of the scenario:
User A fetches the row.
User B fetches the row.
User B modifies the row and successfully submits the changes.
User A modifies the row and successfully submits the changes, overwriting the changes that User B just submitted.
The CommandBuilder object does not offer this optimistic concurrency option; the Data Adapter Configuration Wizard does. On the Advanced Options tab, deselect the Use Optimistic Concurrency check box.
Because the value of the ContactName column for this row of data has changed in the database, no row in the table satisfies all the criteria in the query’s WHERE clause. Thus, the database does not modify the customer row. The DataAdapter queries the database to determine how many rows the query modified, discovers that the query did not successfully update the desired row, and marks the DataRow accordingly. We’ll discuss identifying and resolving such conflicts in Chapter 11.
This is the concurrency option that the CommandBuilder object uses. The Data Adapter Configuration Wizard uses this concurrency option by default.
??????
Include the Primary Key and Timestamp Columns
You can define a timestamp column on your SQL Server table, and any time the contents of a row changes, SQL Server will modify the value of the timestamp column for that row. We can add a timestamp column to the Customers table and change the query in the previous example to look like this:
UPDATE?Customers
????SET?CustomerID?=?'ABCDE',?CompanyName?=?'Original?Company?Name',?
????????ContactName?=?'New?Contact',?Phone?=?'800-555-1212'
????WHERE?CustomerID?=?'ABCDE'?AND?
??????????TimestampColumn?=?0x00000000000000CC
Because the server will generate a new value for the timestamp column each time it updates a row, you can use a combination of the primary key and timestamp columns in the WHERE clause of your query-based updates to ensure that you don’t overwrite another user’s changes.
Most database systems support a similar data type. Some use a unique binary value, and others use a date/time value. Check your database system’s documentation to determine the back end’s data type and learn how you can force the database to update the value each time you modify the contents of a row.
Currently, neither the CommandBuilder nor the Data Adapter Configuration Wizard supports generating updating logic using this optimistic concurrency strategy.
I prefer using the primary key and timestamp columns in my concurrency checks because this option yields much simpler updating logic and the database has fewer columns to examine per update attempt.
Include the Primary Key Columns and Modified Columns
Let’s look at our multi-user example using this updating strategy. Let’s say that User A and User B retrieve the same row of customer data at the same time. They each modify a different column of data—User A changes the Company-Name column, and User B changes the ContactName column. User B submits the pending change to the ContactName column first. User B’s UPDATE query looks like this:
UPDATE?Customers
????SET?ContactName?=?'New?Contact'
????WHERE?CustomerID?=?'ABCDE'?AND?
??????????ContactName?=?'Original?Contact'
User A then submits the pending change to the CompanyName column using the following UPDATE query:
UPDATE?Customers
????SET?CompanyName?=?'New?Company?Name'
????WHERE?CustomerID?=?'ABCDE'?AND?
??????????CompanyName?=?'Original?Company?Name'
The contents of the row will change from
CustomerID??CompanyName????????????ContactName
----------??---------------------??----------------
ABCDE???????Original?Company?Name??Original?Contact
to
CustomerID??CompanyName????????????ContactName
----------??---------------------??----------------
ABCDE???????Original?Company?Name??New?Contact
and finally to
CustomerID??CompanyName????????????ContactName
----------??---------------------??----------------
ABCDE???????New?Company?Name???????New?Contact
Both updates will succeed, and the change made by User A will not overwrite changes made by User B.
The structure of the ADO.NET DataAdapter does not lend itself to this updating strategy because it requires that you change the structure of the query based on the columns that have been modified in the row that contains the pending change. The DataAdapter supplies values for the parameters in its query-based updates on a row-by-row basis, but it does not modify the actual structure of the parameterized query.
Theoretically, you could write code to dynamically change the structure of the appropriate Command object and use that code while handling the DataAdapter object’s RowUpdating event. I think that this updating strategy has benefits, but the costs outweigh them.
referrence:? <<Microsoft?ADO.Net>>
other resources:
http://zitiger.cnblogs.com/archive/2005/08/06/208881.html
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
