2012-03-17 9 views
6

Tengo una estructura de tabla bastante simple como la que se muestra a continuación y me emite sonidos extraños. Aunque he elegido trabajar en torno a esto, pero me gustaría tomar la opinión de los expertos.Entity Framework nvarchar Sensibilidad de mayúsculas y minúsculas en la clave externa

que tiene dos tablas

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 

Atención: Caso de usuario aquí es Caps que es válida en SQL, que acepta.

Ahora la parte divertida. Genere el EDMX, .Net 4.0 y ahora ejecuto este código.

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

Me rompe con la excepción de puntero nulo Usuario1 Lanza nulo, Cuando cambia el valor de la columna nombre de usuario en la tabla Registros de un en lugar de Un funciona.

Este Link habla de algo similar

Este Link otro problema similar

favor, comparta sus respuestas por qué es este comportamiento, clasificación de mi DB mayúsculas y insentivity. ¿Te has enfrentado a algo similar?

Respuesta

7

El problema aquí es que su base de datos no distingue entre mayúsculas y minúsculas, pero CLR (.NET) no lo es y, a diferencia de la base de datos, no puede cambiarse a modo insensible a mayúsculas. Debe hacerlo por comparación.

Cuando llame al item.User1.LastName EF activará la carga diferida - se ejecuta una consulta adicional en la base de datos para cargar un usuario relacionado pero cuando el usuario se materializa EF comenzará a corregir y validar su modelo relacional y aquí surge el problema - compara cadenas con mayúsculas y minúsculas, de acuerdo con esta configuración a no es igual a A y debido a eso su entidad User cargada no es una relación de su entidad Registration. Como resultado, EF no arreglará la propiedad User1 y seguirá siendo nula. Accediendo al LastName en tal caso lanzará NullReferenceException.

sólo hay dos soluciones:

  • reparar su base de datos y asegurarse de que esta diferencia si no apareciera en sus datos de nuevo
  • Si están en el inicio del proyecto o si tiene plena control sobre la base de datos rediseñarlo. NVarChar Las claves principales y las claves externas son un mal diseño de la base de datos.

Si ninguna de estas opciones es aplicable para usted, debe evitar el uso de EF con dicha base de datos.

+0

Tuve que hacer el Punto 1 ya que en este momento no es posible cambiar DB – Kusek

+0

@ladislav Gracias por la respuesta. Esta información no es obvia, pero saber esto me dio la información necesaria para solucionar mi problema. Tuve que luchar con una base de datos heredada muy escamosa con diferentes PK de casos, sobre los cuales no tenía control. Afortunadamente, pude resolver el problema usando una vista y haciendo 'UPPER ([PrimaryKey])' en ambas tablas ofensivas para asegurarme de que coincidieran. Realmente no recomendaría este enfoque, pero tuve que hacerlo para que mi programa funcione. – theyetiman

Cuestiones relacionadas