Lo único a tener en cuenta es que las operaciones en las estructuras de DateTime que representan las columnas de la base de datos no se traducen en SQL. Por lo tanto, no se puede escribir una consulta como:
from e in EfEmployeeContext
where e.DOB.Date > new DateTime(2011,12,01);
... porque e.DOB representa la columna de la fecha de nacimiento en la base de datos, y EF no sabrá cómo traducir la Fecha de sub-propiedad.
Sin embargo, hay una solución fácil dependiendo de qué fechas quiere:
Si desea incluir todos los empleados que tienen una fecha de nacimiento en el 12/01/2011, así como los nacidos después de esa fecha, a continuación, simplemente consulta:
from e in EfEmployeeContext
where e.DOB > new DateTime(2011,12,01);
Si desea incluir sólo los empleados nacidos después del 12/01/2011, a continuación, consulta:
from e in EfEmployeeContext
where e.DOB >= new DateTime(2011,12,02);
En resumen, los criterios, es decir, un DateTime constante o literal con el que compara, se pueden configurar como lo desee. Simplemente no puede hacer modificaciones radicales a las propiedades que representan columnas DB dentro del predicado where. Eso significa que no se puede comparar una columna DateTime a una proyección de otra columna DateTime, por ejemplo:
//get all employees that were hired in the first six months of the year
from e in EfEmployeeContext
where e.HireDate < new DateTime(e.HireDate.Year, 7, 1);
¿Se refiere a Entity Framework (= LINQ to Entities) y LINQ to SQL (pre EF ORM)? – abatishchev
FWIW, si está usando SQL Server 2008 o superior, probablemente debería estar usando 'Date' (en lugar de' DateTime') para campos cuya porción de tiempo sea irrelevante (es poco probable que TENGA la hora del día que alguien nació, y aún menos probable que sea significativo para usted). Usar 'DateTime' cuando' Date' está disponible y no te importa el tiempo sería como almacenar todos tus datos numéricos en un 'float' independientemente de si los datos son intrínsecamente o no. –