2017-11-11 225 views
0

這裏有一個奇怪的錯誤。在我們的ASP.NET 4.6應用中,使用實體框架6.2,當訪問SQL Azure數據庫時,我們得到「用戶登錄失敗」。我很確定錯誤的原因是在Azure中切換層。我沒有得到的是爲什麼沒有發現錯誤。我們所有的SQL操作都在try ... catch塊內。錯誤從塊中消失,並在應用程序崩潰之前被Globals.asax捕獲。 我們有未處理的異常錯誤 - 用戶登錄失敗

SetExecutionStrategy("System.Data.SqlClient", Function() New SqlServer.SqlAzureExecutionStrategy(10, TimeSpan.FromSeconds(7))) 

其中,按照我的理解,將重試任何SQL執行10次,至少70秒內從第一個錯誤。根據微軟技術支持,這不是因爲它尚未與SQL Azure建立連接而參與其中。 ConnectRetryCount和連接字符串中的時間間隔不適用,因爲它正在與服務器通話。服務器只是說,「我知道你在那裏,但我不會讓你進去!」 根據MS Tech的支持,解決這個問題的唯一方法就是圍繞我們所有的SQL命令嘗試...... catch塊......我們這樣做!它只是通過和崩潰的應用程序!

我不能在globals.asax中重試,因爲那時它已經崩潰了。 根據MS,沒有辦法在上下文中捕獲錯誤並從那裏重試。那麼,解決方案是什麼?除了「只是讓應用崩潰並讓他們刷新頁面」之外,還必須有一些答案!

當頁面刷新幾秒後,一切正常。沒有錯誤,沒有問題。

的代碼引發錯誤的線路之一的實例:

MapTo = ctx.BrowserMaps.FirstOrDefault(Function(x) code.Contains(x.NameOrUserAgent)) 

這真的很簡單。這個只是碰巧遇到了很多,因爲這個代碼塊被頻繁調用。實際的SQL請求是不相關的,因爲不管使用哪條線,EF內的連接都會失敗。

回答

2

服務器登錄將斷開連接,同時向上/向下擴展到新層,並且事務回滾。但是,包含的數據庫登錄在擴展過程中保持連接狀態,因此建議通過服務器登錄進行登錄。

嘗試並捕獲可能無法解決問題,因爲您可能正在捕獲錯誤#0,並且Azure SQL數據庫中的很多錯誤落在該錯誤0類別上。

只是一個評論,縮放後的性能可能在縮放後很差,幾分鐘後會提高。查詢計劃也可能會改變。

+0

這或多或少是答案。在我們的例子中,在模型的構造函數中放置一個try.catch允許我們設置一些重試邏輯。我們正在調查數據庫登錄,謝謝。 –