Entity Framework nvarchar Case Sensitivity na klucz obcy

Question

Mam dość prostą strukturę tabeli, jak poniżej i wydaje dziwne dźwięki do mnie. Chociaż zdecydowałem się obejść to, ale chciałbym wziąć opinie ekspertów.

Mam dwie tabele

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 

Uwaga przypadek Użytkownika tutaj jest Caps Jest to ważne w SQL, to akceptuje.

Teraz zabawa. Wygenerowałem EDMX, .Net 4.0 i teraz wykonuję ten kod.

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

To tylko zrywa z Null Pointer Exception User1 Zgłasza Null, Kiedy zmienić wartość nazwa_użytkownika kolumna w tabeli Rejestracje do zamiast to działa.

This Link opowiada o nieco podobny

Ten Link inny podobny problem

Proszę podzielić swoje odpowiedzi, dlaczego jest to zachowanie, Układanie mojego DB jest wielkość insentivity. Czy spotkałeś się z podobnym?

Answer 1

Problem polega na tym, że w bazie danych nie jest uwzględniana wielkość liter, ale CLR (.NET) nie jest i w przeciwieństwie do bazy danych, że nie może być przełączany na tryb globalnie niewrażliwy na wielkość liter - należy to zrobić dla porównania.

Po wywołaniu item.User1.LastName EF uruchomi leniwy ładunek - dodatkowe zapytanie zostanie wykonane w bazie danych w celu załadowania powiązanego użytkownika, ale po zmaterializowaniu użytkownika EF rozpocznie naprawianie i walidację swojego modelu relacyjnego, a tu pojawia się problem - porównuje łańcuchy z uwzględnieniem wielkości liter, więc zgodnie z tym ustawieniem a nie jest równe A i z tego powodu twoja załadowana jednostka User nie jest relacją twojej jednostki Registration. W rezultacie EF nie naprawi właściwości User1 i pozostanie puste. Uzyskanie dostępu do LastName w takim przypadku spowoduje wyświetlenie NullReferenceException.

Istnieją tylko dwa rozwiązania:

• naprawić bazę danych i upewnić się, że różnica ta sprawa nie pojawi się w danych ponownie
• Jeśli jesteś na początku projektu lub, jeśli masz pełny kontrola nad bazą danych to przeprojektować. NVarChar klucze podstawowe i klucze obce są nieprawidłowym projektem bazy danych.

Jeśli żaden z tych wyborów nie dotyczy Ciebie, powinieneś unikać używania EF z taką bazą danych.