並行控制意指多個使用者同時更新資料列時，用於保留資料庫完整性的各種技術。 不正確的並行控制可能導致髒讀、幻讀和不可重複讀取等問題。 Microsoft JDBC Driver for SQL Server 提供介面給 SQL Server 所使用的所有並行技術來解決這些問題。
注意
如需有關 SQL Server 並行的詳細資訊，請參閱＜管理並行資料存取＞。
備註
JDBC 驅動程式支援下列並行類型：
| 並發類型 | 特性 | 資料列鎖 | 描述 |
|---|---|---|---|
| CONCUR_READ_ONLY | 唯讀 | 否 | 不允許透過游標進行更新，且不會對組成結果集的資料列持有任何鎖定。 |
| CONCUR_UPDATABLE | 樂觀式讀寫 | 否 | 資料庫假設資料列競爭不太可能發生，但仍有可能。 資料列的完整性會透過時間戳記比較來確認。 |
| CONCUR_SS_SCROLL_LOCKS | 悲觀式讀寫 | 是 | 資料庫假設可能會發生資料列競爭。 資料列完整性可藉由資料列鎖定來確保。 |
| CONCUR_SS_OPTIMISTIC_CC | 樂觀式讀寫 | 否 | 資料庫假設不太可能發生列爭用，但仍有可能。 資料列的完整性會透過時間戳記比較來確認。 如果是 SQL Server 2005 (9.x) 及更新版本，且資料表不包含時間戳記資料行，伺服器會將其變更為 CONCUR_SS_OPTIMISTIC_CCVAL。 對於 SQL Server 2000 (8.x)，如果其基礎資料表具有 timestamp 資料行，即使已指定 OPTIMISTIC WITH VALUES，仍會使用 OPTIMISTIC WITH ROW VERSIONING。 如果指定 OPTIMISTIC WITH ROW VERSIONING，且資料表沒有時間戳記，則會使用 OPTIMISTIC WITH VALUES。 |
| CONCUR_SS_OPTIMISTIC_CCVAL | 樂觀式讀寫 | 否 | 資料庫假設未必會發生資料列競爭，但是有可能。 資料列的完整性會透過資料列資料比較來確認。 |
不可更新的結果集
可更新的結果集，是指可在其中插入、更新和刪除資料列的結果集。 在下列情況中，SQL Server 無法建立可更新的資料指標。 產生的例外狀況為：「結果集無法更新。」。
| 原因 | 描述 | 補救方法 |
|---|---|---|
| 陳述式不是使用 JDBC 2.0（或更新版本）語法建立的 | JDBC 2.0 推出建立陳述式的新方法。 如果使用 JDBC 1.0 語法，結果集預設為唯讀。 | 建立陳述式時，指定結果集類型與並行。 |
| 使用 TYPE_SCROLL_INSENSITIVE 建立陳述式 | SQL Server 會建立靜態快照游標。 這會與底層資料表資料列分離，以協助保護游標不受其他使用者對資料列所做更新的影響。 | 使用 TYPE_SCROLL_SENSITIVE、TYPE_SS_SCROLL_KEYSET、TYPE_SS_SCROLL_DYNAMIC 或 TYPE_FORWARD_ONLY 搭配 CONCUR_UPDATABLE，以避免建立靜態游標。 |
| 資料表設計使 KEYSET 或 DYNAMIC 游標無法使用 | 基礎資料表沒有唯一的索引鍵，無法讓 SQL Server 唯一識別資料列。 | 將唯一鍵新增至資料表，以識別每個資料列。 |