El proveedor de Oracle Entity Framework no almacena DateTime. Ahora con milisegundos

Tengo básicamente la misma pregunta que este tipo aquí.

¿Por qué no puedo guardar el DateTime actual? Ahora con Entity Framework

Pero él estaba usando SQL Server, y yo estoy usando Oracle. (Mi aplicación debe funcionar con ambos)

Su problema fue que la precisión no se estableció correctamente en el nivel de db.

Me he dado cuenta de que si edito manualmente los milisegundos en mi base de datos de Oracle, EF puede extraer la marca de tiempo correcta en milisegundos. Pero cuando creo una entidad con una propiedad DateTime en “DateTime.Now”, se trunca.

El atributo DateColumn1 es del tipo de Timestamp Oracle

He registrado la statement de inserción

insert into "SchemaName"."TableName"("DateColumn1") values (:P0) --:P0:'5/14/2015 4:07:27 PM' (Type = Date)

Lo loco es que esto funciona en SQL Server.

Jajaja ¡Mi asombroso colega tuvo una idea y funcionó!

En nuestro código EF intentamos poner

 protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Entity().Property(p => p.TIMESTAMP).HasPrecision(6); } 

Y luego el DateTime.Now con milisegundos se almacenó en la base de datos

Actualización: vale la pena mencionar cómo llegué a esta situación.

Construyendo la Base de Datos con el Modelo Primero en una aplicación de “prueba”

  1. Mi aplicación tiene que trabajar tanto con SQL Server como con Oracle. Asi que…
  2. Comencé diseñando mi base de datos en un Diagtwig EDMX.
  3. Una vez que se hizo el diagtwig, generé el DDL para SQL Server.
  4. Por alguna razón, el proveedor de Oracle EF no pudo generar el DDL, así que procedí a hacer cambios manualmente en el DDL de SQL Server para que fuera correcto sintácticamente

    1er problema : mi DDL de Oracle estaba usando una fecha en lugar de una marca de tiempo. Asegúrate de usar la marca de tiempo! DateTime en Oracle no almacena milisegundos.

Usando Code First de la base de datos para la solución real

  1. Quería que la aplicación utilizara el enfoque de Code First (solo mi preferencia. Creo que es más fácil de mantener)
  2. Así que me conecté a la base de datos de SQL Server y generé todas mis clases a partir de ese esquema.
  3. Obtuve todas mis pruebas de unidad y luego decidí probarlo con la base de datos Oracle
  4. Incluso después de cambiar de DATE a Timestamp, seguía teniendo problemas con los milisegundos que entraba.
  5. Generé otro modelo de Code First en una solución de estudio visual de prueba con un tipo de TIMESTAMP(6) en Oracle, excepto cuando miré el código OnModelCreating , no generó nada con HasPrecision(6) ni hubo decoradores en la propiedad en La clase generada de C # POCO.
  6. Noté que si tiene el HasPrecision(6) en su OnModelCreating , el Code First CreateDatabase() creará un Oracle TIMESTAMP(6) . Si no lo hace, entonces el proveedor de Oracle EF utilizará la DATE

Creo que si utiliza el enfoque de Model First puede establecer valores de precisión en el diagtwig EDMX, pero he escuchado que es una mala práctica.

Quería agregar a lo anterior porque un poco de esto me confundió y me envió por el camino equivocado. Los campos de fecha no deben usar la anotación TIMESTAMP como intenté hacer. Los campos en su clase de POCO deben permanecer como DateTime:

  public class TimeClass { public DateTime? StartTime { get; set; } public DateTime? StopTime { get; set; } } 

Luego, en la creación de modelos para cada uno de los campos de Fecha en cada una de sus Clases Modelo, debe establecer la precisión de los campos

  protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.HasDefaultSchema("MySchema"); //see [here][2] modelBuilder.Entity().Property(p => p.StartTime).HasPrecision(6); modelBuilder.Entity().Property(p => p.StopTime).HasPrecision(6); } 

Entonces puedes obtener los milisegundos. El tiempo con segundos se registra de forma predeterminada con el campo DateTime