2017-08-04 59 views
0

我目前面臨的問題是需要花費相當長的時間來處理來自服務器的信息,並且我希望爲用戶提供主動反饋,以便知道應用程序看起來正在發生什麼。C#:從SqlConnection對象獲取反饋?

有關應用程序:它允許用戶從指定的服務器中提取所有數據庫以及這些數據庫中的所有內容。這可能需要相當長一段時間,因爲我們的一些數據庫可以達到2TB的大小。每個服務器可以包含數百個數據庫,因此,如果我嘗試使用100個數據庫加載服務器,並且其中30%的數據庫大小超過100GB,那麼在應用程序能夠運行之前需要幾分鐘的時間再次有效。

目前我只是有一個簡單的加載消息說:「請稍等,這可能需要一段時間...」。但是,在我看來,這對於需要幾分鐘時間的事情來說並不足夠。

因此,我想知道是否有辦法跟蹤SqlConnection對象的進度,因爲它正在執行指定的查詢?如果是這樣,我可以提供什麼類型的細節,並且是否有現成的資源可供查看並更好地理解解決方案?

我希望有一種方法可以做到這一點,而不必重新創建SqlConnection對象。

謝謝大家的幫助!

編輯

此外,作爲另注;我不在這裏尋找代碼的講義。如果有任何可用的情況,我正在尋找能夠幫助我解決這種情況的資源。我一直在調查這個問題已經有幾天了,我想這裏最好的地方就是尋求幫助。

額外

一個更詳盡的解釋:我想知道是否有提供與當前正在接收數據庫,表,視圖等名用戶的方式。

例如:

  • 負載表X從數據庫是開服務器ž
  • 加載表格從數據庫B在服務器ž
+0

只是一個想法在這裏。讓您的代碼在啓動SQL作業後立即返回的SPROC啓動。該sproc應該返回一個標識用戶作業的GUID,以便用戶可以查詢狀態。該作業可以將進度記錄寫入表中,您可以查詢該表。連接不需要保持打開狀態,用戶應用程序不需要保持打開狀態。它全部斷開連接。 GUID將用於檢索有關作業的信息並有選擇地控制作業。 – Amy

+1

您可以將查詢分解爲較小的查詢,並在每個階段完成後向用戶界面報告。 – Amicable

+0

請看,這就是爲什麼當我卡住時,我會問StackOverflow問題。但是,性能會有什麼影響?這是否會顯着降低處理速度?在加載每個數據庫的詳細信息之前,我可以輕鬆地提取數據庫名稱列表,並通過該列表循環以提供反饋。 – lxxtacoxxl

回答

1

關閉SqlConnection有一個InfoMessage-事件,其中將您可以分配一個方法。此外,您必須將FireInfoMessageEventOnUserErrors-Property設置爲true。 不,你可以這樣做

private void OnInfoMessage(object sender, SqlInfoMessageEventArgs e) 
    { 
     for (var index = 0; index < e.Errors.Count; index++) 
     { 
      var message = e.Errors[index]; 
      //use the message object 
     } 
    } 

請注意,你應該只用較低的則11(一切上面是一個「真正的」錯誤)的錯誤代碼評估的消息。

根據您使用的是什麼命令,服務器已經生成了這樣的信息消息(例如在VERIFY BACKUP中)。

反正你也可以用它來報告存儲過程或查詢的進度。

僞代碼(IM不是sqlguy):

RAISEERROR('START', 1,1) WITH NOWAIT; -- Will raise your OnInfoMessage-method 
WHILE 
-- Execute something 
RAISEERROR('Done something', 1,1) WITH NOWAIT; -- Will raise your OnInfoMessage-method 
-- etc. 

END 

與解析樂趣,因爲請記住:這種消息也可以由服務器本身生成的(所以它可能是開始自己的一個好主意,相關的「錯誤」與在正常情況下不會發生的飽和序列)。

+0

從我的理解中,這個例子只會返回執行SPROC或查詢的錯誤相關的信息?我可能會感到困惑。這是一個很有用的信息,因爲它提供了有關錯誤反饋的信息。 – lxxtacoxxl

+0

是的,這是正確的。反正沒有理由不能濫用「錯誤」來返回進度信息。例如:如果你知道你需要執行n個查詢(你以前確定過),你可以在開始時產生一個「錯誤」,告訴你需要執行n個查詢。然後在執行每個查詢後生成一個「錯誤」,因此您可以向客戶報告進度。 – BudBrot

+0

我會爭辯說,只要你選擇的動詞是「濫用」,那麼解決方案應該放在backburner上,直到其他解決方案耗盡。不要認爲這是一個糟糕的解決方案,只是沒有被描述爲「濫用」的解決方案應該是首選。 – Amy