實體框架nvarchar對外鍵的大小寫敏感性

我有如下相當簡單的表結構，對我來說聽起來很奇怪。儘管我已經選擇瞭解決這個問題，但是想徵詢專家意見。實體框架nvarchar對外鍵的大小寫敏感性

我有兩個表

Users 
UserName nvarchar(250) Primary Key 
FirstName nvarchar(50) 
LastName nvarchar(50) 

Registrations 
Id BigInt PrimaryKey 
User nvarchar(250) - Foreign to Users Table 
Date - DateTime 

Data I have is as follows. 
Users 
UserName FirstName LastName 
a  Small  A 
b  Small  B 

Registrations 
Id  User  Date 
1  A   1/1/12 
2  B   1/1/12

請注意用戶的案例這裏是大寫它是SQL有效，它接受。

現在有趣的部分。我生成了EDMX，.Net 4.0和現在我執行這個代碼。

using (EFTestEntities context = new EFTestEntities()) 
      { 
       var item = context.Registrations.Where(id => id.Id == 1).FirstOrDefault(); 
       Response.Write(item.User1.LastName); 
      }

它只是空指針異常用戶1打破拋出空，當我更改用戶名列的值註冊人數表一個代替一個它的工作原理。

大約有幾分相似

這Link另一個類似的問題，這Link會談

請分享你的答案爲什麼這種行爲，我的數據庫的排序規則是區分insentivity。你有沒有面對類似的？

來源

2012-03-17 Kusek

的這裏的問題是，你的數據庫是不區分大小寫，但CLR（.NET）是不是和對比數據庫不能切換到全球範圍內不區分大小寫模式 - 你必須這樣做每比較。

當你調用item.User1.LastName時，EF會觸發延遲加載 - 在數據庫中執行額外的查詢以加載相關用戶，但是當用戶物化時，EF將開始修復和驗證其關係模型，並且出現問題 - 比較字符串區分大小寫所以根據該設置a不等於A和因爲你的加載User實體不是你Registration實體的關係。因此EF不會修復User1屬性，它將保持爲空。在這種情況下訪問LastName將拋出NullReferenceException。

只有兩種解決方案：

修復數據庫，並確保這種情況下差異不會再次出現在您的數據
如果你是在項目的開始，或者如果你有充分的控制數據庫重新設計它。主鍵和外鍵都是數據庫設計不好的主要原因。

如果這兩種選擇都不適用於您，則應避免在此類數據庫中使用EF。

來源

2012-03-17 17:48:24

我不得不做點1是在這一點DB變化不是的答案可能 – Kusek 2012-03-18 04:27:46

@ladislav感謝。這些信息不是顯而易見的，但瞭解這一點給了我解決我的問題所需的見解。我不得不用一個非常薄的遺留數據庫來處理不同的案例PK，這是我無法控制的。幸運的是，我能夠通過使用視圖並在兩個違規的表上執行'UPPER（[PrimaryKey]）'來解決問題，以確保它們匹配。我真的不會推薦這種方法，但我必須這樣做才能讓我的程序正常工作。 – theyetiman 2017-02-02 10:20:09

實體框架nvarchar對外鍵的大小寫敏感性

回答

相關問題