使用SQL Server的朋友應該都知道，在SQL Server 2005中處理錯誤，最重要的因素是@@ERROR變量。每個語句執(zhí)行以后，你必須查詢這個變量值，以保證沒有使事務回滾的錯誤發(fā)生。這種方法有些麻煩，更重要的是，還容易出錯。另外，在SQL Server 2000中能夠處理的錯誤類型僅限于某些類型的錯誤。終止事務或批處理的錯誤就無法處理，也沒有詳細的錯誤信息。
TRYCATCH
SQL Server 2005提供TRYCATCH結構，它出現(xiàn)在許多現(xiàn)代迭代程序語言之中，如Java和C#中。此結構讓你通過CATCH結構中的一系列新函數(shù)訪問更為詳細的錯誤信息，這些函數(shù)包括：
ERROR_NUMBER：返回錯誤號碼，與@@ERROR的值相同。
ERROR_SEVERITY：返回調用CATCH塊錯誤的嚴重程度。
ERROR_STATE：返回錯誤狀態(tài)號碼。
ERROR_LINE：返回錯誤發(fā)生的行號。
ERROR_PROCEDURE：返回促使錯誤發(fā)生的存儲程序和觸發(fā)器的名稱。
ERROR_MESSAGE：返回錯誤的完整信息文本。
在CATCH塊內(nèi)，你可以在任何地方應用這些函數(shù)，它們將返回與發(fā)生的錯誤有關的信息。在CATCH塊外，這些函數(shù)返回零值。
處理死鎖錯誤
讓我們來看一個例子，了解如何應用SQL Server 2005中的新錯誤處理功能來處理死鎖情形，在SQL Server 2000的數(shù)據(jù)庫級別下，這種問題幾乎無法處理。
計算機中存在資源競爭就會發(fā)生死鎖。這種情形并非僅發(fā)生在數(shù)據(jù)庫管理系統(tǒng)中，還發(fā)生在操作系統(tǒng)或其他任何出現(xiàn)資源爭奪的系統(tǒng)中。當一個進程鎖定特定的資源，而又需要另外的資源來完成任務時，就會發(fā)生死鎖。如果另一個進程鎖定了第一個進程需要的資源，而且還需要第一個進程獲得的資源，就會出現(xiàn)僵局。兩個進程都不愿釋放自己的資源，意味著兩個進程都不能完成自己的任務。
不過，SQL Server中本身就存在一個運算法則，在這種情形下，它會隨機選擇一個失敗者，這個失敗者釋放自己的資源以便另一個進程能夠完成自己的任務。這就意味著那個被終止的進程必須再次嘗試。在SQL Server 2000及更早的版本中，解決這種情形的方法是在業(yè)務層專門針對死鎖編寫代碼，如果探測到死鎖情況，就再次嘗試事務。隨著時間的推移，如果你注意到死鎖情形發(fā)生的趨勢，你就可以在存儲程序中包括邏輯，設定死鎖的優(yōu)先權。這種方法允許你在死鎖情形下選擇失敗者，但你無法再次嘗試被終止的進程。
用SQL Server 2005，你能夠在數(shù)據(jù)層發(fā)現(xiàn)錯誤，這樣業(yè)務層開發(fā)人員就不必擔心事務再次嘗試問題。如果你能夠發(fā)現(xiàn)一個死鎖錯誤，你就需要再次嘗試語句（可能要在一段時間之后，以便釋放所需的資源）。
為說明這些新功能的運作情況，查看列表A。表中的代碼用來記錄發(fā)生的錯誤。我希望記錄錯誤處理函數(shù)的所有信息，以及錯誤發(fā)生的日期和發(fā)生錯誤的數(shù)據(jù)庫。
我將用列表B中的代碼來記錄程序中發(fā)生的所有錯誤。注意你不必給程序設定任何參數(shù)，此程序將訪問上面描述的錯誤處理函數(shù)。這是因為在執(zhí)行CATCH塊的時候，你可以調用這個程序。即使調用了其他程序，你也可以在CATCH塊的任何地方參考這些函數(shù)。
列表C專門用來查檢死鎖錯誤號，此時為1205。如果FicticiousTable1更新時發(fā)生死鎖錯誤，語句即被重試三次。如果重試三次后還不能成功更新，就停止更新此表。
SQL Server 2005錯誤處理的優(yōu)點
與之前的版本相比，SQL Server 2005提供了一種更為穩(wěn)健的錯誤處理工具。在SQL Server 2000數(shù)據(jù)庫層幾乎無法處理的死鎖問題，現(xiàn)在也能輕松解決。
SQL Server 2005提供TRYCATCH結構，它出現(xiàn)在許多現(xiàn)代迭代程序語言之中，如Java和C#中。此結構讓你通過CATCH結構中的一系列新函數(shù)訪問更為詳細的錯誤信息，這些函數(shù)包括：
ERROR_NUMBER：返回錯誤號碼，與@@ERROR的值相同。
ERROR_SEVERITY：返回調用CATCH塊錯誤的嚴重程度。
ERROR_STATE：返回錯誤狀態(tài)號碼。
ERROR_LINE：返回錯誤發(fā)生的行號。
ERROR_PROCEDURE：返回促使錯誤發(fā)生的存儲程序和觸發(fā)器的名稱。
ERROR_MESSAGE：返回錯誤的完整信息文本。
在CATCH塊內(nèi)，你可以在任何地方應用這些函數(shù)，它們將返回與發(fā)生的錯誤有關的信息。在CATCH塊外，這些函數(shù)返回零值。
處理死鎖錯誤
讓我們來看一個例子，了解如何應用SQL Server 2005中的新錯誤處理功能來處理死鎖情形，在SQL Server 2000的數(shù)據(jù)庫級別下，這種問題幾乎無法處理。
計算機中存在資源競爭就會發(fā)生死鎖。這種情形并非僅發(fā)生在數(shù)據(jù)庫管理系統(tǒng)中，還發(fā)生在操作系統(tǒng)或其他任何出現(xiàn)資源爭奪的系統(tǒng)中。當一個進程鎖定特定的資源，而又需要另外的資源來完成任務時，就會發(fā)生死鎖。如果另一個進程鎖定了第一個進程需要的資源，而且還需要第一個進程獲得的資源，就會出現(xiàn)僵局。兩個進程都不愿釋放自己的資源，意味著兩個進程都不能完成自己的任務。
不過，SQL Server中本身就存在一個運算法則，在這種情形下，它會隨機選擇一個失敗者，這個失敗者釋放自己的資源以便另一個進程能夠完成自己的任務。這就意味著那個被終止的進程必須再次嘗試。在SQL Server 2000及更早的版本中，解決這種情形的方法是在業(yè)務層專門針對死鎖編寫代碼，如果探測到死鎖情況，就再次嘗試事務。隨著時間的推移，如果你注意到死鎖情形發(fā)生的趨勢，你就可以在存儲程序中包括邏輯，設定死鎖的優(yōu)先權。這種方法允許你在死鎖情形下選擇失敗者，但你無法再次嘗試被終止的進程。
用SQL Server 2005，你能夠在數(shù)據(jù)層發(fā)現(xiàn)錯誤，這樣業(yè)務層開發(fā)人員就不必擔心事務再次嘗試問題。如果你能夠發(fā)現(xiàn)一個死鎖錯誤，你就需要再次嘗試語句（可能要在一段時間之后，以便釋放所需的資源）。
為說明這些新功能的運作情況，查看列表A。表中的代碼用來記錄發(fā)生的錯誤。我希望記錄錯誤處理函數(shù)的所有信息，以及錯誤發(fā)生的日期和發(fā)生錯誤的數(shù)據(jù)庫。
我將用列表B中的代碼來記錄程序中發(fā)生的所有錯誤。注意你不必給程序設定任何參數(shù)，此程序將訪問上面描述的錯誤處理函數(shù)。這是因為在執(zhí)行CATCH塊的時候，你可以調用這個程序。即使調用了其他程序，你也可以在CATCH塊的任何地方參考這些函數(shù)。
列表C專門用來查檢死鎖錯誤號，此時為1205。如果FicticiousTable1更新時發(fā)生死鎖錯誤，語句即被重試三次。如果重試三次后還不能成功更新，就停止更新此表。
SQL Server 2005錯誤處理的優(yōu)點
與之前的版本相比，SQL Server 2005提供了一種更為穩(wěn)健的錯誤處理工具。在SQL Server 2000數(shù)據(jù)庫層幾乎無法處理的死鎖問題，現(xiàn)在也能輕松解決。