[Entity Framework]IQueryable v.s. IEnumerable

由於先前遇到Entity Framework會有Cache的狀況，而注意到IQueryable以及IEnumerable。

大部分操作LINQ皆預設採用IQueryable的形式進行，以獲得對於資料庫調教後的查詢效能。

基本上兩者的差異如下：

IEnumberable為將整份完整資料載入應用程式記憶體中進行操作。

IQueryable則為類似組SQL字串的模式，將操作轉換為對應SQL字串，直到實際取得資料時才從資料庫中取回資料。(可以把他想成它就是在做LINQ語法與查詢字串之間的轉換)

[C#]Windows Forms 在不同機器上控制項跑版的原因與解法

是的，我必須承認，當初我找到自己寫的第一支程式並沒有那麼順利。

當我興高采烈地開啟專案時，卻看到...

這到底甚麼鬼，WinForm上面的控制項都不在自己應該有的位置上！

Designer.cs裡面定義的控制項座標還跟設計畫面上的不一樣！

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

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

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

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

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

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

[心情分享] 回顧大一(2008)時的期末專案 - Pacman(小精靈)

突然心血來潮，看看自己的GitHub近況(Traffic、Fork...)，發現多多少少還是有人會來參觀，網路上的夥伴每個動作都給我莫大的鼓勵啊！

[Entity Framework]原來是Cache！用AsNoTracking()揭穿他的真面目！

很好，太好了，我又見鬼啦！

但是我並不害怕，我盯著他看了好久好久，閉著眼都可以畫出他的樣子。

就讓我好好的描述描述他到底長個甚麼樣！

小弟我使用Entity Framework製作讀取資料庫中關聯式資料，實作中將DbContext.Configuration.LazyLoadingEnabled設定為true，便可以在一次執行中將所有關聯資料都同時撈出放在單一實體中。

但是，在一次讀取後，根據讀取的關聯資料進行修改並再次讀取時，恐怖的事情就發生啦！

剛剛更改的東西讀不到啊！

[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' 中的系統記憶體不足，無法執行此查詢。