J'utilise EF (modèle EDMX - dB en premier) pour mapper "Timeestamp avec le fuseau horaire" à un DateTimeOffset. Lorsque je commette le DateTimeOffset à Oracle, la partie de zone est ignorée de manière incorrecte.
Donc, si vous utilisez le modèle, par exemple, d'insérer la valeur J'ai débogué dans "oracle.dataaccess.dll" (en utilisant iLspy :)) et j'ai constaté que le code de mappage pour EF omettez la zone (le "Oracle Data Fournisseur" ne transmet que le fichier DateTimeOffset.datetime uniquement).
Est-ce que quelqu'un connaît une solution de contournement?
Merci d'avance
Eli
BTW: J'utilise .NET4, EF4, Oracle 11G, ODAC 11.2 Libération 4 (11.2.0.3.0) 29/02/2012 10:10:10 +04: 00 , la valeur qui est réellement stockée dans Oracle est 29/02/2012 10:10:10 +02: 00 (supposant +02: 00 est une zone locale)
Notez que les mappages fonctionnent simplement bien lorsque vous interrogeez les données. Seul Insérer (via ObjectContext.Savechanges ()) est cassé ...
3 Réponses :
Vous pouvez essayer de dynamiquement Définir le fuseau horaire de la session , qui "prend effet lorsqu'une valeur d'horodatage est convertie en horodatage avec Fuseau horaire ou horodatage avec type de type de fuseau horaire local ".
... un terrible hack, également parce que vous ne pouvez pas exécuter directement la session directement via SQL. Vous devez utiliser quelque chose comme P>
begin DBMS_UTITLITY.EXEC_DDL_STATEMENT ('Alter Session Set TIME_ZONE = ''+04:00'''); end;
Oracle a admis c'était un bug https://community.oracle.com/thread / 2360615? TSTART = 0 . Et ils ont été tristes que cela avait été corrigé dans Bug 13851978. Mais mon test sur Oracle Client sur 11.2.0.3.0 est toujours échoué.
On Solution est que @HAL 9000 a suggéré de définir le fuseau horaire de la session avec les heures et les minutes en période de temps de DateTimeOffset avant d'économiser sur la base de données. Mais cela ne fonctionnera pas s'il y a plusieurs propriétés DateTimeOffset dans un objet et ces propriétés ont des températures différentes à l'intérieur DateTimeOffset.
Une autre alternative remplace ODP.net avec un fournisseur de données tiers, tel que DotConnect de Devart (j'ai testé cela, cela fonctionne pour moi). Il existe une comparaison sur Stackoverflow sur différents fournisseurs de données https://stackoverflow.com/a/8298684/1443505 .
Stockage des compensations dans la base de données peut ne pas contenir de bonne qualité pour la gestion du compensation de la journée. Ce sera une bonne pratique pour toujours utiliser des noms de fuseau horaire sur les valeurs de décalage lorsque le but n'est pas affecté.
--To store actual time and timezone value
to_timestamp_tz('10-SEP-2014 01:40:00.000000000 US/Pacific','DD-MON-YYYY HH24:MI:SS.FF9 TZR')
--To store actual time at timezone converted to UTC timezone value for uniformity
to_timestamp_tz('10-SEP-2014 01:40:00.000000000 US/Pacific','DD-MON-YYYY HH24:MI:SS.FF9 TZR') at time zone 'UTC'