Changement de comportement de java.SQL.Date après la mise à niveau du client OJBC

Après une mise à niveau du client OJDBC de la version 11.2.0 à 12.1.0, je rencontre un comportement différent dans la liaison d'un java.SQL.Objet Date à un PreparedStatement.

Dans l'instruction préparée, une variable hôte " f. plan_date=?"devrait être lié avec la valeur d'un java.util.Objet Date, étant une entrée obtenue ailleurs dans le code. Le type de données de colonne dans la table Oracle est "DATE" et seule la partie date doit être prise en compte - l'heure n'est pas pertinente.

J'ai traduit Java.util.Objet Date dans un java.SQL.Objet Date de la manière suivante: statementRegisterJobs.setDate(3, new java.sql.Date(planDate.getTime()));

Cela a bien fonctionné avec le client 11.2.0. Cependant, les choses ont tendance à mal tourner après la mise à niveau vers 12.1.0. Aucun enregistrement n'est récupéré plus. Après des heures de débogage, j'ai découvert que le problème était lié à la variable date. La façon suivante de travailler me rend mes dossiers: statementRegisterJobs.setDate(3, java.sql.Date.valueOf("2014-08-21"));

Quelqu'un Pourrait-il clarifier ce comportement? Java.util.Objet Date peut éventuellement avoir un temps composant, et j'ai le sentiment indéfini que cela pourrait être lié au problème d'une manière ou d'une autre. D'autre part, les éléments suivants devraient soutenir qu'un composant temporel est négligé dans un java.SQL.Date, peu importe comment l'objet a été construit...

  • Dans l'API Java 6 pour java.SQL.Date, j'ai trouvé la déclaration suivante: "Cette méthode est obsolète et ne doit pas être utilisée car les valeurs de date SQL n'ont pas de composant temporel."(méthode 'getHours()'). Donc, ce serait dire que le temps aspect est négligé lors de la conversion du java.util.Date dans un java.SQL.Date.
  • Ceci est confirmé par les informations de la documentation du constructeur: "Construit un objet Date en utilisant la valeur de temps en millisecondes donnée. Si la valeur en millisecondes donnée contient des informations de temps, le pilote définira les composants de temps sur l'heure du fuseau horaire par défaut (le fuseau horaire de la machine virtuelle Java exécutant l'application) qui correspond à zéro GMT."
  • De plus, je ne suis pas capable pour obtenir un aspect temporel possible du java.SQL.Objet Date: toString() ne me donne que la date, getHours () lève une exception.
  • Et comment cela peut-il être lié à une mise à jour dans un client JDBC?

Toutes les pensées sont appréciées :) Merci beaucoup d'avance.

Author: Wouter, 2014-08-22
Source

1 answers

Opposé à ce que l'API Java indique, lors de la création d'un java.SQL.Objet Date en passant une valeur de temps en millisecondes, l'aspect temps semble être stocké dans l'objet et n'est pas mis à zéro par défaut lors de l'utilisation du pilote 12.1.0 OJDBC.

C'est le test que j'ai mis en place: 

java.util.Date utilDate = new Date();
java.sql.Date sqlDate1 = new java.sql.Date(utilDate.getTime());
java.sql.Date sqlDate2 = java.sql.Date.valueOf("2014-08-27");

J'ai préparé l'instruction suivante (SELECT to_char(?, 'YYYY-MM-DD HH24:MI:SS') testDate FROM dual), lié à la fois sqlDate1 et sqlDate2 et obtenu les résultats suivants.

  1. Avec la version du pilote 11.2.0

    • sqlDate1: 2014-08-27 00:00:00
    • sqlDate2: 2014-08-27 00:00:00

  2. Avec la version du pilote 12.1.0

    • sqlDate1: 2014-08-27 14:47:29
    • sqlDate2: 2014-08-27 00:00:00

Ce n'est pas conforme à la documentation de l'API:

Si la valeur de millisecondes donnée contient des informations de temps, le pilote règle le temps de composants à l'heure dans le fuseau horaire par défaut (le fuseau horaire de la machine virtuelle Java exécutant l'application) qui correspond à zéro GMT .

Cependant, sachant cela, je peux résoudre le problème en forçant les informations de temps de l'objet sql date à minuit.

 6
Author: Wouter, 2014-08-27 15:23:29