小生用以下代碼，將客戶端連接到局域網的另一臺機子上，打開一個客戶端的時候，多能進行正常操作，打開二個，有一個是沒有反應的，這是怎么回事。是那里的代碼要改動，要怎么改呢，大俠幫忙一下。
// Profile ydf
SQLCA.DBMS = "OLE DB"
SQLCA.LogId = "sa"
SQLCA.AutoCommit = true
SQLCA.DBParm = "PROVIDER='SQLOLEDB',DATASOURCE='192.168.31.163',PROVIDERSTRING='database=BYD2015'"
connect using sqlca;
uj5u.com熱心網友回復：
這是連接資料庫的，連接幾個應該都沒有問題，主要是看資料庫設定的最大連接數，你的問題估計不是出在這里，是出在其它代碼了
uj5u.com熱心網友回復：
sqlca.lock='RC'uj5u.com熱心網友回復：
這個問題在SQL SERVER里頭叫阻塞，并不是真正的死鎖。原因是由于多方面因素引起的：
1、最主要的原因是SQL SERVER 默認使用的是read commit, 而普通程式使用的加鎖級別都是read uncommit. 使用read uncommit(也就是臟讀)會影響資料的一致性，但并不是所有的處理都需要加鎖。由于你的程式比較舊，所以我考慮沒有對需要加鎖的事務仔細分析，導致每讀資料都要加鎖，這個鎖會和其他SELECT鎖，和UPDATE的更新鎖沖突，導致程式彼此等待，尤其是PB的DW，要么不使用事務，要么使用的事務比較長，那么如果有個伙計SELECT了資料不關閉他的DW，而這個DW又處于一個長事務中，其他的人只好等待等待，這樣鎖越加越多，就只好死機啦。
2、第二個原因與第一個原因類似，但是一般發生在類似代碼表這樣的表上，因為這類表被頻繁訪問，因此就形成了處理時候一個非常非常熱的點。由于一所說的SELECT鎖在這里很容易發生，因此更容易造成阻塞。另外，對于比較小的熱點表，SQL SERVER處于性能考慮的原因，在頻繁訪問的情況下，會自動將行鎖升級為表鎖。一旦升級為表鎖，那么其他訪問表的行程就只好死翹翹了。
處理的方法很簡單：
1、并不是所有的地方都需要使用read commit的加鎖級別，你從application中設定一句sqlca.lock="RU", 使用臟讀，這樣就可以去掉大多數不必要的SELECT行鎖。然后在一定要讀最新資料的地方，把SQLCA。LOCK改為RC，用完后再改回來。
這樣就避免了幾乎80%的阻塞。
2、對于由于行更新，或者其他UPDATE導致的鎖，一般資料庫會自己協調，在事務比較長的情況下，這需要你對原來的程式做適當的修改。把長事務變為幾個小的事務，在事務中做更新操作，不要插入用戶的互動。這是系統的設計原則。
如果你的系統對事務的要求不嚴格，又不想改動原來的程式，辦法更簡單，在前面
SQLCA。LOCK的基礎上，加句SQLCA。AUTOCOMMIT=TRUE，這樣每資料修改自動提交，就可以避免大多數由于更新產生的死鎖和阻塞。
3、最后要對付的是剛才說的被大量應用頻繁訪問的表（HOT TABLE），如果你的系統允許使用RU加鎖級別，那么不用太考慮，因為SELECT已經不會導致鎖定了。
但是如果你不能使用RU方式（1里頭提到的辦法），
那么要采用這樣的手段：
使用索引把更新鎖，SELECT鎖來分開，同時也避免SQLSERVER傻傻為了性能的原因把行鎖升級為表鎖。
具體辦法是建立一個索引，如果可以的話使用聚集索引，因為聚集索引采用的是類似HASH的檢索方式，這樣當查找索引的時候，就不需要訪問資料表了。
另一種辦法，是將你SELECT陳述句中要檢索的資料都加到索引中，例如你檢索NAME，SEX，AGE，如果你把三個資料都加入了索引，這就意味著SELECT陳述句只要找到索引，就已經找到了最后要選取的資料（從索引中），這樣自然不會去LOCK表了。這樣做的時候要針對你的程式仔細選擇索引，否則把索引變成了表的一個備份就沒有意義了。
總結一下，就三招：
1、降低加鎖級別，2、可能的話使用自動提交 3、采用措施避免表訪問的熱點
當然，必要的時候優化你的應用程式，仔細劃分事務也是很重要的。
uj5u.com熱心網友回復：
關于MS SQL中lock屬性
RU Read Uncommitted
RC Read Committed
RR Repeatable Read
TS Serializable
查閱SQL SERVER2005聯機叢書有以下描述：
sql server 資料庫引擎隔離級別
SQL-99 標準定義了下列隔離級別，Microsoft SQL Server Database Engine 支持所有這些隔離級別：
未提交讀（隔離事務的最低級別，只能保證不讀取物理上損壞的資料）
已提交讀（資料庫引擎 的默認級別）
可重復讀
可序列化（隔離事務的最高級別，事務之間完全隔離）
實際測驗發現，當設定sqlca.lock='RR'可重復讀時，會出現死鎖，其他三種不會。似乎PB10以上版本預設是sqlca.lock='RR'才會造成死鎖。
一般是用“RC”，低版本的PB用MSS連接時的默認級別，適用于大多數情況，當然還要看你的具體應用了
uj5u.com熱心網友回復：
版主大拿，解釋的非常清楚，收藏
uj5u.com熱心網友回復：
可能就是執行了陳述句未提交,導致加鎖uj5u.com熱心網友回復：
你少了一個引數sqlca.lock='RC'
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/34815.html
標籤：數據庫相關
上一篇：[PB]求解決
下一篇：PB已經消失了嗎？