對于ADO處理要非常的謹慎，我們的大多數beta版產品的質量都同Microsoft已發布的產品的質量是一樣的，只有對數據準確性要求極高并且用戶可以忍受等待的情況下，使用這種并發沖突的處理方法。

1. 放任不管方式：

與其說這是一種處理并發沖突的方式，不如說，它是一種沒有對并發沖突做任何處理的方式。但是在許多過去的系統里，由于沒有考慮到多用戶、網絡應用等情況，這種"處理方式"還真存在于不少系統中。

舉例來說，A、B兩人從數據庫中獲取了同一個筆記本的信息，例如：IBM ThinkPad T61吧。然后：A把牌子改成了：Lenovo ThinkPad，B把型號改成了T61 8890A24。然后，他們開始提交了。此時，如果A先提交，然后B提交，那么，最后的結果是：IBM ThinkPad T61 8890A24ADO處理；反之，則變成Lenovo ThinkPad T61。

總之一句話，誰最后提交誰老大。想像一下，如果A修改了1000個屬性的值，B修改了1個屬性的值，那么，對于先提交的A來說，這將是一個多么慘痛的打擊:-) 雖然這種放任不管的方式似乎不太負責任，但是，其處理性能卻是相對較高的。

2. 開放式并發處理

開放式并發處理，老外叫做Optimistic Concurrency——樂觀的并發。這種并發處理方式要求我們對并發抱有一種樂觀的態度：百分之九十九點九九不會發生并發沖突，萬一發生了，系統也能捕獲到沖突，或者根據策略自動處理，或者，就提醒一下用戶，讓用戶來決定是不是要繼續提交。

仍然用上面的例子來說這事兒：A、B兩個人同時獲取了筆記本的信息：IBM ThinkPad T61。然后……（此處跟上例做一樣的修改，直到提交）此時，如果A先提交，那么，B提交的時候，系統會發現，哎喲，不好，有并發沖突了，就會拋個異常給B，讓B知道，發生并發沖突了ADO處理，然后，B就可以根據實際情況，選擇相應的處理策略（比如，繼續提交進行覆蓋或者取消提交等等）；相反，如果B先提交，那么，A提交時，就會得到相應的提醒。 #t#

這樣的并發處理方式，可以說在可靠性與性能上取得平衡，適合于對數據可靠性要求不是特別嚴格，需要較高的性能，并且不會大量發生并發的場合。

3. 保守式并發ADO處理

這是最為嚴謹的一種并發沖突的處理方式。它把并發轉化為了串行操作。 例如，A從數據庫中獲取了筆記本信息：IBM ThinkPad T61，B也要對其進行修改，但此時由于A已經從數據庫中將數據取出，因此，B被置于等待狀態。直到A把數據修改完提交了，ADO處理數據庫數據更新為Lenovo ThinkPad T61了，此時，數據庫才把數據給B，那么B就可以在Lenovo ThinkPad T61的基礎上，把它修改為Lenovo ThinkPad T61 8890A24。而在B提交前，其它一切針對此記錄的操作都得排除等著B。

這樣子當然非常理想，由于不存在并發，自然也就消除了并發沖突的問題。但是，ADO處理這種鎖也存在著較為隱蔽的風險：如果A修改了數據，一直不提交，或者A因為故障，沒有辦法提交，那么，其它所有的相關的操作，都將被阻礙住。因此，只有對數據準確性要求極高并且用戶可以忍受等待的情況下，使用這種并發沖突的處理方法。