Ah! Meu colega incrível teve uma ideia e funcionou!
Em nosso código EF, tentamos colocar
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<EntityClass>().Property(p => p.TIMESTAMP).HasPrecision(6);
}
E então o
DateTime.Now
com milissegundos foi armazenado no banco de dados Atualização - vale a pena mencionar como cheguei nessa situação
Construindo o banco de dados com o Model First em um aplicativo de "teste"
- Meu aplicativo precisa funcionar com SQL Server e Oracle. Então...
- Comecei projetando meu banco de dados em um diagrama EDMX
- Depois que o diagrama foi feito, gerei o DDL para SQL Server.
-
Por algum motivo, o provedor Oracle EF não conseguiu gerar o DDL, então continuei a fazer alterações manualmente no DDL do SQL Server para que ele ficasse sintaticamente correto
1º problema - meu Oracle DDL estava usando uma data em vez de timestamp. Certifique-se de usar Timestamp!!! DateTime no Oracle não armazena milissegundos.
Usando Code First do banco de dados para a solução real
- Eu queria que o aplicativo usasse a abordagem Code First (Apenas minha preferência. Acho que é mais fácil de manter)
- Conectei-me ao banco de dados SQL Server e gerei todas as minhas classes a partir desse esquema.
- Todos os meus testes de unidade foram aprovados e decidi testá-los com o banco de dados Oracle
- Mesmo depois de mudar de DATE para Timestamp, ainda estava tendo problemas com os milissegundos.
- Gerei outro modelo Code First em uma solução de estúdio visual de teste com um
TIMESTAMP(6)
digite no Oracle, exceto quando olhei para oOnModelCreating
código, não gerou nada comHasPrecision(6)
nem havia decoradores na propriedade na classe C# POCO gerada. - Percebi se você tem o
HasPrecision(6)
código em seuOnModelCreating
, o Code FirstCreateDatabase()
irá realmente fazer um OracleTIMESTAMP(6)
. Caso contrário, o provedor Oracle EF usaráDATE
Acho que se você fizer a abordagem Model First, poderá definir valores de precisão no diagrama EDMX, mas ouvi dizer que é uma prática ruim.