[Oracle9i] Requête dynamique et date

[Drizzt [Drone38]]

Bonjour,

Cela fait pas mal de temps que je planche sur le problème suivant :

Dans une procédure stockée située dans un package, je construit une requête dynamique. La construction est de la forme suivante :

Code :

1
2
3
4
5
6
7
8
9
v_req := '
insert into (...) (
  select ...
    from ...
  where ...
     and t.date1 < to_date(''' || to_char(vDate,'DD/MM/YYYY') || ''',''DD/MM/YYYY'')
     and t.date2 >= to_date(''' || to_char(vDate,'DD/MM/YYYY') || ''',''DD/MM/YYYY'')
     and ...
)';

Cela fonctionne chez moi en Oracle8i et Oracle9i.
vDate est une variable globale de type DATE.

Sur un autre environnement j'ai une erreur assez sévère d'Oracle. L'erreur remontée depend de l'environnement appelant (Plus de données sur le socket pour un appel jdbc, fin de fichier sur canal de communication depuis TOAD).
Dans le fichier alert.log on a des erreurs de ce type : ORA-07445: exception encountered: core dump [] [] [] [] [] [].

Si je remplace le to_date(...) par un bête sysdate cela fonctionne.

Si je remplace vDate par une variable locale cela plante aussi.
Si j'extrait la procédure dans un fichier sql, que j'initialise mes variables globales en début de procédure et que je lance ce fichier sql, cela fonctionne.

Bref je ne comprend plus grand chose. J'ai essaye de changer mes parametres NLS_DATE_FORMAT & co chez moi pour tenter de reproduire mais sans succès.

Merci d'avance pour vos idées.

[McM]

En fait c'est la solution la moins sujette aux divers problèmes de formattage de date, vu que tu reconstruit la date à partir d'une chaine de caractère.

Donc je ne vois pas pourquoi ça planterait.

Essayes d'utiliser des bind variables pour tester

[SheikYerbouti]

Sinon mettre en phase le format date dès le début du traitement avec

Code :

execute immediate 'alter session set nls_data_format=''DD/MM/YYYY''';

ensuite, il ne sera plus nécessaire d'utiliser les fonctions de conversion to_date() et to_char()

[mnitu]

Envoyé par SheikYerbouti

Sinon mettre en phase le format date dès le début du traitement avec

Code :

execute immediate 'alter session set nls_data_format=''DD/MM/YYYY''';

ensuite, il ne sera plus nécessaire d'utiliser les fonctions de conversion to_date() et to_char()

Franchement, dans ce cas je ne vois pas comment.
Il pourrair s'en passer plutôt en utilisant des variables de liaison (binding variables) (suggèré déjà par MCM)
Sinon pour l'anomalie il faut chercher peut être sur Metalink, Ora-07445

[SheikYerbouti]

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Connected TO:
Oracle DATABASE 10g Express Edition Release 10.2.0.1.0 - Production
 
SQL> SELECT sysdate FROM dual;
 
SYSDATE
---------
22-APR-08
SQL>
SQL>  declare
  2  lc$date date;
  3  begin
  4  execute immediate 'alter session set nls_date_format=''dd/mm/yyyy''';
  5  lc$date := sysdate ;
  6  dbms_output.put_line(sysdate || '-' || lc$date);
  7  end;
  8  /
22/04/2008-22/04/2008
 
PL/SQL procedure successfully completed.

[Drizzt [Drone38]]

La solution avec les bind variables fonctionne.
Mais je ne comprend toujours pas pourquoi ma solution ne fonctionnait pas dans cet environnement particulier.

Je n'ai pas testé la solution de SheikYerbouti car d'une part j'avais la même question que mnitu et d'autre part, les tests étant effectués par le client maintenant qu'une solution est trouvée, je ne peux décemment leur demander d'effectuer d'autres tests (vu le nombre déjà effectué...)


Merci à tous.
Je ne met pas le tag Résolu car j'aimerai bien une explication ou du moins une piste d'explication, je n'aime pas avoir une solution sans comprendre l'origine initiale du problème.

[mnitu]

Pour @SheikYerbouti

Syntax
DBMS_OUTPUT.PUT_LINE (
item IN VARCHAR2);

et pour que ça marche avec sysdate et lc$date Oracle fait une conversion to_char implicite (voilà la revenu par la fenêtre). Et se baser sur des conversions implicites ...

Code :

1
2
3
4
5
6
7
8
9
10
 
  1  SELECT dump(sysdate), dump(sysdate||' ')
  2* FROM dual
 
DUMP(SYSDATE)
--------------------------------------------------------------------------------
DUMP(SYSDATE||'')
--------------------------------------------------------------------------------
Typ=13 Len=8: 7,216,4,22,10,7,11,0
Typ=1 Len=9: 50,50,47,48,52,47,48,56,32

Pour @Drizzt
Connais tu la valeur de la variable globale vDate avant d'éxécuter le code qui se plante ?

[Drizzt [Drone38]]

Oui je l'ai vérifié.
Et j'ai même remplacé cette dernière par une variable locale déclarée juste avant la requête sans succès.

Par contre la même chose hors du package fonctionne (dans un fichier sql lancé depuis SQL+). Et la seule différence de paramètres de session est le NLS_DATE_FORMAT qui est à DD-MM-RR dans un cas et DD-MM-YY dans l'autre. Mais j'ai changé ce dernier dans mon environnement sans reproduire l'erreur (je n'ai pas pu tester dans l'autre sens, voir si l'erreur disparaissait chez le client).