更新 SQL Server 資料指標中的資料
透過 SQL Server 資料指標提取和更新資料時，SQL Server Native Client OLE DB 提供者取用者應用程式會由套用到其他任何用戶端應用程式的相同考量和條件約束所繫結。
只有在 SQL Server 資料指標中的資料列會參與並行的資料存取控制。 取用者要求可修改的資料列集時，並行控制會由 DBPROP_LOCKMODE 所控制。 若要修改並行存取控制的層級，取用者會先設定 DBPROP_LOCKMODE 屬性，然後再開啟資料列集。
如果用戶端應用程式設計讓交易長時間保持開啟狀態，交易隔離等級可能會對資料列定位造成重大落後。 根據預設，SQL Server Native Client OLE DB 提供者會使用 DBPROPVAL_TI_READCOMMITTED 所指定的讀取認可隔離等級。 當資料列集並行唯讀時，SQL Server Native Client OLE DB 提供者支援中途讀取隔離。 因此，取用者可以在可修改的資料列集中要求較高的隔離等級，但是無法成功要求任何較低的等級。
立即和延遲更新模式
在立即更新模式下，IRowsetChange::SetData 的每個呼叫會造成 SQL Server 的往返。 如果取用者對單一資料列進行多個變更，利用單一 SetData 呼叫提交所有變更比較困難。
在延遲更新模式下，SQL Server 的往返是針對 IRowsetUpdate::Update 之 cRows 和 rghRows 參數中指示的每個資料列進行。
在任一種模式下，當資料列集沒有開啟任何交易物件時，往返代表不同的交易。
當您使用 IRowsetUpdate::Update 時，SQL Server Native Client OLE DB 提供者會嘗試處理每個指示的資料列。 因為任何資料列的資料、長度或狀態值無法所產生的錯誤不會停止 SQL Server Native Client OLE DB 提供者處理。 參與更新的其他所有資料列或沒有任何資料列可能會遭到修改。 當 SQL Server Native Client OLE DB 提供者傳回 DB_S_ERRORSOCCURRED 時，取用者必須檢查傳回的 prgRowStatus 陣列來判斷是否有任何特定的資料列發生錯誤。
取用者不應該假設資料列會以任何特定順序處理。 如果取用者需要透過一個以上的單一資料列進行資料修改的排序處理，取用者應該以應用程式邏輯建立該順序，並開啟交易來包含程序。