在最近的一篇文章中，我講過如何在SQL Server2000中發現問題。在SQL Server 2005中處理錯誤，最重要的因素是@@ERROR變量。每個語句執行以后，你必須查詢這個變量值，以保證沒有使事務回滾的錯誤發生。這種方法有些麻煩，更重要的是，還容易出錯。另外，在SQL Server 2000中能夠處理的錯誤類型僅限于某些類型的錯誤。終止事務或批處理的錯誤就無法處理，也沒有詳細的錯誤信息。

　　TRYCATCH

　　SQL Server 2005提供TRYCATCH結構，它出現在許多現代迭代程序語言之中，如Java和C#中。此結構讓你通過CATCH結構中的一系列新函數訪問更為詳細的錯誤信息，這些函數包括：

　　ERROR_NUMBER：返回錯誤號碼，與@@ERROR的值相同。

　　ERROR_SEVERITY：返回調用CATCH塊錯誤的嚴重程度。

　　ERROR_STATE：返回錯誤狀態號碼。

　　ERROR_LINE：返回錯誤發生的行號。

　　ERROR_PROCEDURE：返回促使錯誤發生的存儲程序和觸發器的名稱。

　　ERROR_MESSAGE：返回錯誤的完整信息文本。

　　在CATCH塊內，你可以在任何地方應用這些函數，它們將返回與發生的錯誤有關的信息。在CATCH塊外，這些函數返回零值。

　　處理死鎖錯誤

　　讓我們來看一個例子，了解如何應用SQL Server 2005中的新錯誤處理功能來處理死鎖情形，在SQL Server 2000的數據庫級別下，這種問題幾乎無法處理。

　　計算機中存在資源競爭就會發生死鎖。這種情形并非僅發生在數據庫管理系統中，還發生在操作系統或其他任何出現資源爭奪的系統中。當一個進程鎖定特定的資源，而又需要另外的資源來完成任務時，就會發生死鎖。如果另一個進程鎖定了第一個進程需要的資源，而且還需要第一個進程獲得的資源，就會出現僵局。兩個進程都不愿釋放自己的資源，意味著兩個進程都不能完成自己的任務。

　　不過，SQL Serve中本身就存在一個運算法則，在這種情形下，它會隨機選擇一個失敗者，這個失敗者釋放自己的資源以便另一個進程能夠完成自己的任務。這就意味著那個被終止的進程必須再次嘗試。在SQL Server 2000及更早的版本中，解決這種情形的最佳方法是在業務層專門針對死鎖編寫代碼，如果探測到死鎖情況，就再次嘗試事務。隨著時間的推移，如果你注意到死鎖情形發生的趨勢，你就可以在存儲程序中包括邏輯，設定死鎖的優先權。這種方法允許你在死鎖情形下選擇失敗者，但你無法再次嘗試被終止的進程。

　　用SQL Server 2005，你能夠在數據層發現錯誤，這樣業務層開發人員就不必擔心事務再次嘗試問題。如果你能夠發現一個死鎖錯誤，你就需要再次嘗試語句（可能要在一段時間之后，以便釋放所需的資源）。

　　為說明這些新功能的運作情況，查看列表A。表中的代碼用來記錄發生的錯誤。我希望記錄錯誤處理函數的所有信息，以及錯誤發生的日期和發生錯誤的數據庫。

　　我將用列表B中的代碼來記錄程序中發生的所有錯誤。注意你不必給程序設定任何參數，此程序將訪問上面描述的錯誤處理函數。這是因為在執行CATCH塊的時候，你可以調用這個程序。即使調用了其他程序，你也可以在CATCH塊的任何地方參考這些函數。

　　列表C專門用來查檢死鎖錯誤號，此時為1205。如果FicticiousTable1更新時發生死鎖錯誤，語句即被重試三次。如果重試三次后還不能成功更新，就停止更新此表。

　　SQL Server 2005錯誤處理的優點

　　與之前的版本相比，SQL Server 2005提供了一種更為穩健的錯誤處理工具。在SQL Server 2000數據庫層幾乎無法處理的死鎖問題，現在也能輕松解決。利用這些新功能，你能夠將更多精力放在IT商業策略開發上，不用過于關注錯誤處理。