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跟蹤輸出！

本文到此結束！