[Entity Framework]provider: Session Provider, error 19 - 實體連接不可用

最近利用ASP.NET MVC5搭配Entity Framework寫了一個小功能，監控資料表數量！

該程式每30秒會採polling的方式向SQL Server詢問目前資料表中的資料數量，並顯示在網站頁面中。

經同事報案，在執行過程中不定時會發生Exception，錯誤描述如下：

在接收來自伺服器的要求時發生傳輸層級的錯誤。 

(provider: Session Provider, error 19 - 實體連接不可用)

[SQL Server]關於T-SQL的錯誤處理(Error Handling)

真沒想到這麼快就又見面了！

趁著記憶猶新，趕緊來記錄一下小弟我所發現關於SQL Server動態T-SQL的Error Handling現象。

一般來說，T-SQL錯誤處理的方法有兩種。

1. 使用@@ERROR系統全域變數：

此全域變數會記錄上一個T-SQL語句查詢的結果，也就是說隨著執行過程，@@ERROR會一直改變。

也就是說，如果是一串的SQL指令，每一句都需要做Error Handle的話，可能使用下一種方法會更為合適。

2. 使用TRY...CATCH：

就跟一般高階語言(C#、JAVA等)的用法類似，就不再贅述了...

進入重頭戲啦！

[SQL Server]CREATE/ALTER DATABASE不能使用Transaction

果然是失敗、錯誤中學習成長，即便是有Common Sense就可以了解的東西，我仍然可以試出不可行的方法，可見我武藝精深、非同小可。

近來需要實作動態建立SQL Server資料庫，小弟我只能想到利用動態T-SQL來實作，一切都進行得很順利，但是突然靈光一閃~阿要是建失敗了怎麼辦？

這怎麼可能難的倒我呢！包上Transaction不就搞定啦！

於是我蹲好馬步，順著這股氣勢寫了一段SQL...

[SQL Server]使用InMemory記憶體最佳化發生系統記憶體不足，無法執行此查詢之錯誤

為了增加針對SQL Server在寫入以及讀取上的效能，將特定資料表採用InMemory的技術，
能大幅增加資料查詢的時間，使用起來異常痛快，但哪知還是採到地雷啊！

特此筆記之。

測試過程中持續寫入至InMemory資料表中，直到記憶體都被塞滿了吐出這樣的錯誤訊息。
資源集區 'default' 中的系統記憶體不足，無法執行此查詢。