2012-03-17 2 views
6

У меня довольно простая структура таблицы, как показано ниже, и проблема звучит странно для меня. Хотя я решил обойти это, но хотел бы получить мнение экспертов.Entity Framework 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 

Пожалуйста, обратите внимание, Случай пользователя здесь Caps она действительна в SQL, он принимает.

Теперь Fun часть. Я создал EDMX, .Net 4.0 и теперь я выполняю этот код.

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

Это просто срывает с Null Pointer Exception Пользователя1 Броски Null, когда я изменить значение UserName Колонка в Регистраций таблице вместо это работает.

Это Link говорит о несколько сходных

Link Это еще один аналогичный вопрос

Пожалуйста, поделитесь своими ответы почему такое поведение, Collation моей БД случай-insentivity. Вы сталкивались с подобным?

ответ

7

Проблема заключается в том, что ваша база данных нечувствительна к регистру, но CLR (.NET) не является и, в отличие от базы данных, она не может быть переключена на нечувствительный к регистру режим в глобальном масштабе - вы должны сделать это за сравнение.

Когда вы вызываете item.User1.LastName EF запускает ленивую загрузку - в базу данных загружается дополнительный запрос в базу данных, но когда пользователь материализуется, EF начнет фиксировать и проверять свою реляционную модель, и здесь возникает проблема - она ​​сравнивает строки с чувствительностью к регистру, поэтому в соответствии с этим значением a не равен A, и из-за этого ваш загруженный объект User не является отношением вашего объекта Registration. В результате EF не исправит свойство User1 и оно останется нулевым. Доступ к LastName в таком случае будет кидать NullReferenceException.

Есть только два решения:

  • исправить вашу базу данных и убедитесь, что эта разница случае не будет появляться в ваших данных снова
  • Если вы в начале проекта, или если у вас есть полный контроль над редизайном базы данных. NVarChar Первичные ключи и внешние ключи - это плохой дизайн базы данных.

Если ни один из этих вариантов не применим для вас, вы должны избегать использования EF с такой базой данных.

+0

Мне нужно было сделать точку 1, так как на данный момент изменение БД невозможно – Kusek

+0

@ladislav Спасибо за ответ. Эта информация не совсем очевидна, но, зная это, я дал понять, что нужно для решения моей проблемы. Мне пришлось бороться с очень раздробленной базой данных с разным корпусом ПК, на который я не контролировал. К счастью, я смог решить проблему, используя представление и сделав 'UPPER ([PrimaryKey])' на обеих таблицах, чтобы убедиться, что они совпали. Я бы действительно не рекомендовал этот подход, но мне пришлось это сделать, чтобы моя программа работала. – theyetiman

Смежные вопросы