我有一個使用相同存儲過程創建記錄然後附加詳細記錄的±20客戶端的分佈式部署。我們注意到主記錄的標識字段存在差距。在這種情況下，我們沒有使用事務，所以我們能夠彌補差距的唯一原因是其中一位開發人員正在某個地方吞下異常。有沒有一個失敗的查詢或查詢列表引發異常記錄的地方？SQL Server 2000會記錄在任何地方產生錯誤的查詢嗎？
是否有任何其他建議去的問題查詢之外：
SQL Server 2000（及更高版本）不會自動記錄生成單純「數據」錯誤的查詢。它將日誌查詢生成嚴重錯誤（例如RAISERROR級別20及以上），並且任何此類錯誤將記錄在Windows應用程序事件日誌中。然而，看起來很可能無論是什麼原因導致你的遊戲都不會產生這類錯誤，因爲現在你可能已經注意到了其他問題。
正如chadhoc所說，試圖找到這個活動的一種方法是設置一個跟蹤來監視它。這樣做超過20多臺服務器跨越多少天，然後分析結果，這是一項不重要的任務。 （我會配置第一次通過異常事件，並根據您的應用程序，批量啓動，存儲過程啓動或RPC啓動之一）。
另一種策略：而不是一個鏡像表填充「擴展」您的存儲過程，請在填充日誌表的表上嘗試一個INSERT觸發器。 （這將捕獲所有插入，而不僅僅是存儲過程完成的插入。）日誌表將跟蹤ID，插入時間以及任何其他您可能認爲有用的信息（誰執行登錄，調用應用程序，以及其他任何可用於調試的數據）。它可能最終看起來像一個鏡像表，但它不一定是。如果差距仍然存在，那麼你肯定知道你的交易被回滾了。 （請記住，如果只是第一個INSERT語句失敗，並且該行從未插入，它仍會「用盡」一個標識值。）
沒有辦法讓信息從SQL 2000以外的情況使用跟蹤（雖然我推薦一個server-side-trace over using profiler像往常一樣）。您可以輕鬆地將跟蹤限制爲包括僅包含該表的批處理啓動/結束事件以及事務啓動/結束和異常事件類。
注意，也有其他的方法你可以得到認同的差距，包括：
間隙通常來自插入被回滾的時間。不必在顯式事務中回滾。例如，假設你有一個日期字段，並且有人爲那個不是有效日期的字段發送一個輸入值。插入將失敗並被回滾，從而導致身份值出現空白。
你永遠無法期待身份領域沒有差距。它根本不會發生。