I:寫本篇博客文章的起因
本小蝦昨天按照項目進度安排在做一個項目模塊，里面有一個功能就是將客戶錄入好的Excel文件(Excel2003/2007)通過后台管理網站上傳並導入至MSSQL數據庫內的表里。
心想這個小case應該難度不大。博主便選擇了NPOI 2.0.1（beta1）加EF 4.1去開發。結果碰到一個很莫名其妙的錯誤。所以才有幸寫下這篇博客文章！記錄一下以免各位遇到相同情況的時候可以注意一下。
II:EF 4 CodeFirst調試基礎知識
不管是EF還是LINQ2SQL還是其他ORM，他們底層基本上都是使用ADO.NET的原生類庫去操作讀寫數據庫的。作為開發人員我們迫切需要有一個工具可以監視得到ORM提交給MSSQL的T-SQL腳本命令以方便進行排bug，在此本人推薦各位使用MSSQL自帶的SQL Server Profiler。它的打開方式如下：
切記Express版本的SQL Server是沒有集成這個工具的。
跟蹤一個數據庫的當前正在執行的腳本信息
打開SQL Server Profiler，點擊[文件] –> [新建跟蹤] 登陸到數據庫服務后跳轉到如下圖示： 
注意勾選[顯示所有列]的復選框，緊接着單擊[列篩選器]按鈕。在彈出的對話框當中設置需要監視的DatabaseID(不知道自己數據庫是那個Id的可以執行[select * from sys.databases]查看)
輸入好數據庫ID過濾篩選條件后點擊[確定]，然后再點擊[運行]按鈕，最終效果圖如下圖示： 
添加數據庫ID篩選條件的作用在此我簡單介紹一下，它可以幫助我們過濾掉一些毫無意義的腳本命令，讓我們更加關心跟蹤對象本身。
關於SQL Server Profiler的工具欄及菜單我就不一一介紹了。接下來還是進入正題！
III:工作任務當中出現的詭異錯誤
進行編碼工作的調試時發現EF報錯，錯誤的原因盡然是EF 4.1往MSSQL上提交了一條全為空的字符串信息從而導致表的外鍵約束規則異常： 
.NET異常圖，由於List<T>的數量巨大。所以無法一一定義到底是那一個對象的屬性值是"空"。
對應上述.NET異常跟蹤到的T-SQL顯示EF提交的sql既然是由於插入了N''空字符串導致外鍵約束驗證出錯。
對此樓主的做法時加入了一個變量它的作用就是將空白的對象打入log內。
var logVal = List.Select(m => string.IsNullOrEmpty(m.Key)).ToList();
再進行一輪反復【修改代碼 <--> 調試】后，發現出錯的原因盡然是Excel文件內最后空出來的幾行沒有被刪掉卻被NPOI讀出來后當成N''插入到數據庫里面去了。所以才會法傷上面插入N’’字符串引發的外鍵約束報錯。
果斷對其下症Fixbug：
最后成功執行導入的截圖： 
IV：結論
請相信機器是根據人的意願去執行代碼的。大多數情況下不會無端端執行出錯（比如胡亂插入幾行N’’空記錄）。
因此，對於經常使用ORM的我們來說學會抓取ORM執行的t-sql已經是一門必備的技能了，另外在程序代碼方面也要做好完善的log跟蹤輸出！
本文到此結束！