使用鍵列，使用
更新，然後每次連接完成後記得及時發布。例如，檢索完成後，記得使用resetupdate()及時清除數據狀態。然後，
在每次數據庫更新之後，也就是update()，記住使用
ll_num1=。更新()
如果ll_num=1，則
提交；
dw_free.resetupdate()
其他
回滾；
Messagebox("提示！""數據保存失敗！")
如果…就會結束
我不同意上述說法:
1.首先，AutoCommit=TRUE，然後delete、update和insert語句都相當提交。如果把幾個SQL語句看成壹個完整的事務，就不應該是完整的。
正文成功提交，或者回滾，這樣寫不會得到正確的結果。
2.其次，key列，use update應該在特定的情況下使用。這種形式並發性最差，適合對數據並發性要求不高的場合。
3.第二期節目僵局的原因有很多，以上兩個方面只是原因。具體情況進行分析，如盡快提交數據，建立合理的指標和合理的SQ。
l語句，避免交叉事務，把數據量巨大的表及時轉移到歷史庫，我覺得可以很大程度上避免死鎖。
以上拙見，歡迎拍磚。
在MSSQL控制臺中，管理-當前活動-鎖/進程ID查看哪些進程死鎖，然後在進程信息/中殺死這些死鎖的進程
優化查詢
還建議檢查:外鍵有索引，如果有索引，調試網絡。
索引外鍵可以緩解這個問題。
例如，在商品字典和銷售清單中，銷售清單中的商品編號是壹個外鍵。如果銷售清單中的商品編號上沒有索引，則更新商品字典將導致銷售清單。
鎖定整個表。
Sybase數據庫死鎖的解決方案
中國人民銀行吉林市中心支行科技司劉誌明
在聯機事務處理(OLTP)數據庫應用系統中，多用戶多任務的並發性是系統最重要的技術指標之壹。為了提高並發性，大多數RDBMS采用
使用鎖定技術。然而，由於現實環境的復雜性，使用鎖技術不可避免地會導致死鎖。因此，如何合理有效地使用加鎖技術，最大限度地減少死鎖呢？
在線交易處理的關鍵。
死鎖的原因
在聯機事務處理中，崩潰有兩個主要原因。壹方面，由於多用戶多任務的並發性和事務完整性的要求，在多個資源上處理多個事務時，
當同時訪問資源時，如果雙方都鎖定了壹些資源，但都需要另壹方鎖定的資源，如果不能在有限的時間內完全獲得所需的資源，他們將處於無限的等待列表中。
狀態，導致它在資源需求上出現死鎖。
另壹方面，數據庫本身的鎖機制的實現方法是不同的，每個數據庫系統也會產生其特殊的死鎖情況。例如，在Sybase SQL Server 11中，最小鎖是每頁2K。
的鎖定方法代替了行級鎖定。如果壹個表中的記錄數量少，記錄長度短(即記錄密度高，如應用系統中的系統配置表或系統參數表)
，訪問頻率高，很容易在這個頁面上產生死鎖。
幾種死鎖情況及解決方法
在清算應用系統中，容易出現死鎖的幾種情況如下:
●不同的存儲過程、觸發器和動態SQL語句段以不同的順序同時訪問多個表；
●添加交換過程中記錄頻繁的表，但對表使用非聚集索引；
●表中記錄少，單個記錄短，所以被頻繁訪問；
●整表訪問頻繁(如代碼對照表查詢)。
上述死鎖情況的相應處理方法如下:
●系統實現時，應規定在所有存儲過程、觸發器和動態SQL語句段中，對多個表的操作始終使用相同的順序。例如，有兩個存儲過程，proc1，proc2，
每個人都需要訪問三個表zltab、z2tab和z3tab。如果proc1按照zltab、z2tab、z3tab的順序訪問它們，那麽proc2也應該按照上面的順序訪問這三個表。
看好了。
●對於交換過程中頻繁添加記錄的表，使用聚集索引減少用戶向表的最後壹頁添加記錄的次數，導致表尾出現熱點和死鎖。
。這類表多為往來賬戶流水賬，其特點是在交換期間需要在表末添加大量記錄，不刪除或很少刪除添加的記錄。
●對於單個表中記錄較少，交換時頻繁選擇或更新數據的表，可以采用設置每頁最大行數的方法，降低表中存儲數據的密度，模擬行級。
鎖來減少表上死鎖的發生。這些表格大多是信息復雜、記錄少的表格。
如:系統配置表或系統參數表。定義該表時，添加以下語句:
max_rows_per_page=1
●在存儲過程、觸發器和動態SQL語句段中，如果對某些整表的select操作比較頻繁，可能會導致與其他用戶訪問表的死鎖。接受檢查
非關鍵語句，如帳號是否存在，但檢查時不會更新選中的字段，可以在select命令中使用at isolation read uncommitted子句。
方法來解決。這種方法實際上降低了select語句對整個表的鎖級別，提高了其他用戶對表操作的並發性。當系統在高負載下運行時，這種方法特別有效。
了不起。
例如:
select *從標題中隔離讀未提交
●對於流水號等流水號生成器字段，可以先執行updata流水號字段+1，然後執行選擇的方法獲取流水號。
總結
在對同城清算系統進行壓力測試時，作者分別對采用上述優化方法和未采用優化方法的兩個系統進行了測試。在其他條件相同的情況下，同樣的事情
事務數相同的時候，死鎖發生的情況如下:
采用優化方法的系統:0次/萬筆交易；
無優化方法的系統:50 ~ 200次/萬筆交易。
因此，使用上述優化方法後，效果尤為顯著，尤其是在系統高負載運行時。總之，在設計和開發數據庫應用系統，尤其是OLTP系統時，我們應該基於
根據應用系統的具體情況，按照上述原則對系統進行優化，為開發高效可靠的應用系統打下良好的基礎。
體驗:
1:前臺問題:檢查代碼，看事情是提交了還是回滾了。
2.背景問題:有時由於所處理問題的高度復雜性。數據庫日誌空間已滿或不足。
導致東西無法提交。UNIX下的SYBAE就是壹個典型的例子。每個數據庫供應商對該解決方案都有更詳細的解釋。
雖然我從9換到10的時候遇到了很多問題，浪費了好幾天時間，但是我現在真的覺得10比9好。
10沒有MSSQL接口，使用OLEDB接口。在使用這個接口的時候，壹定要註意壹個問題:表死鎖！
網上的連接方式都是世界壹大抄。
使用OLEDB並添加SQLCA。Lock = "RC "。
否則，即使查詢也會死鎖。
另壹個是10寫的軟件不再亂碼，我用傳統模式寫的軟件在簡化模式下不亂碼，反之亦然。
第三是編譯速度明顯更快。
第四是編譯時有XP風格的皮膚，感覺好看多了。
如果想養成良好的編程習慣，sql語句插入更新後要及時提交，數據窗口更新()後也要及時提交；
阻塞是因為多個進程對同壹資源的訪問存在沖突。當壹個進程獨占訪問壹個資源時(從進入事務到事務結束)，當其他進程需要訪問同壹個資源時，
樣本資源，即阻塞(根據鎖的級別和粒度設置)；
在實際應用中，阻塞可能是由於事務未提交、網速慢或大容量數據查詢造成的。
阻塞可以通過sp_who系統存儲過程查看，執行sp_who不等於後查看所有blk。
0，直到SPID出現在blk列，但blk列的當前spid =0，即它是阻塞的來源。
最簡單的方法是使用kill SPID(源進程的SPID值)，同時結合sp_lock進程，可以查看當前進程的鎖定情況(比如鎖定類型為lock的對象)。
最後，最重要的是在查詢來源後使用DBCC INPUTBUFFER (spid)檢查最後壹次提交的內容，從而找到事務未提交導致的阻塞(
壹般不能使用AutoCommit=True，因為大部分MIS程序都需要使用批量提交來保證數據的完整)。
/bbs/forumdisplay.php？f=6
編程的時候可能註意力不集中。在SQLCA(事務)中，默認情況下AutoCommit = false(無自動提交)。在同壹事務中，如果事務未提交，
您可以選擇和檢索，但其他事務(其他計算機的應用程序連接到數據庫的事務)不能。所以導致死鎖，這在單機開發環境下是看不到的。
妳需要在所有Update和DELETE的SQL語句之後，或者在數據窗口的UPDATE函數調用之後，執行COMMIT或者ROLLBACK。
死鎖的可能原因和解決方法
壹個偶然的機會，在論壇上看到壹個關於死鎖(其實是阻塞)的帖子，就拿出我的壹個小東西和大家分享壹下。沒想到很多人都遇到過這種情況。
問題
其實解鎖並不是根本的解決辦法。感覺有點誤導妳了，所以有以下內容。希望妳能根據自己的應用找出根本原因，而不是解鎖:
擁塞的可能原因和解決方案；
1.交易未提交。
這是最常見的阻塞原因，因為默認情況下PB會自動啟動事務。如果執行update、delete、insert語句，如果不執行Commit(
不建議自動提交交易，原因在之前的帖子裏已經解釋過了)，解決方法也很簡單。找到所有的數據修改命令(u，I，d)看是否正常提交，找到。
到達時只需加入Commit
2.SQL SERVER沒有正常安裝SP3。
對於代碼正常的用戶，還是有堵塞的，所以需要檢查壹下自己機器的補丁，尤其是WIN2003的機器不安裝補丁，1433無法監控；如果補丁沒有安裝
只是(我被這種情況傷害了)
3.當然妳可能會跟我說代碼沒問題，補丁也裝了。如果它仍然出現，您需要檢查您的機器(運行taskmgr)的CPU和內存使用情況。
服務器機器高峰狀態可能被阻塞，解決方法是付費:升級服務器；
4.復雜的查詢或者大容量的查詢，比如在壹個查詢中使用多個表的聯合查詢，或者使用in，not in之類的語句，都是非常耗時的，這個解決方案稍微復雜壹點。
雜點，需要根據妳的應用修改SQL語句，優化SQL效率。SQL優化是另壹個復雜的話題，我也在學習。...
我想我能想到的就這些了。它可能並不完美。希望有人能補充壹下！
編程的時候可能註意力不集中。在SQLCA(事務)中，默認情況下AutoCommit = false(無自動提交)。在同壹事務中，如果事務未提交，
您可以選擇和檢索，但其他事務(其他計算機的應用程序連接到數據庫的事務)不能。所以導致死鎖，這在單機開發環境下是看不到的。
妳需要在所有Update和DELETE的SQL語句之後，或者在數據窗口的UPDATE函數調用之後，執行COMMIT或者ROLLBACK。
另外，除了在執行Update、Delete、Insert insert時需要及時提交之外，因為SQL Server中使用了Tempdb數據庫，所以這個數據庫是所有用戶共享的。
可以，在使用sum、count等統計SQL函數時。，SQL Server會自動使用Tempdb臨時存儲統計數據，這樣很容易造成Tempdb被鎖定，所以又被讀取。
應該提交復雜的存儲過程或臨時表來釋放Tempdb資源。向檢索到的事件添加commit是壹種解決方案，尤其是在讀取時。
在報告之後，還應該加上壹句。壹般來說，報表的存儲過程比較復雜。在將SQL遊標嵌入程序以讀取數據之後，應該使用commit添加它。我試著鎖上，找了很久才找到。