Discussion :

[pascalT]

Bonjour à tous,
je suis en cours de tests après migration d'une BD Oracle 8 vers 10g.
La migration a été effectuée sans soucis (apparement) avec les outils d'export et d'import de dump.
J'en arrive au problème. J'ai une requete qui sélectionne des données sur plusieurs tables et suivant la clause WHERE, j'obtiens le superbe message :

ORA-01858: Caractère non numérique trouvé à la place d'un caractère numérique

J'ai identifié la table d'où provient cette erreur, mais je ne vois pas comment je peux obtenir un tel message avec un SELECT tout basique.

SELECT champ1, champ2, ....
FROM table1, table2, ...
WHERE (table1.PK = table2.FK)
AND ...
(TO_DATE(TO_CHAR(DATEFACTURATION,'DD/MM') || '/2007','DD/MM/YYYY') >= TO_DATE('30/06/2007','DD/MM/YYYY')) AND
(TO_DATE(TO_CHAR(DATEFACTURATION,'DD/MM') || '/2007','DD/MM/YYYY') <= TO_DATE('31/07/2007','DD/MM/YYYY'))

Si j'enleve la partie rouge du WHERE, la requete fonctionne.
Si j'ajoute au SELECT TO_DATE(TO_CHAR(DATEFACTURATION,'DD/MM') || '/2007','DD/MM/YYYY') , la requete fonctionne encore

Cette erreur est-elle en rapport avec une migration incorrecte ?

Comment peut-on avoir ce message avec un SELECT ?

Le paramètre NLS_DATE_FORMAT peut-il changer qq chose ?

Je précise que toutes mes dates ont le format DD/MM/YYYY (ou semblent l'avoir).



Toute piste est la bienvenue. Merci

Merci

[McM]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
SELECT TO_DATE(TO_CHAR(TO_DATE(NULL),'DD/MM') || '/2007','DD/MM/YYYY')
FROM dual

=> ORA-01858 a non-numeric character was found where a numeric was expected

[pascalT]

Bien tenté, mais ce n'est pas possible, car :
- dans mon WHERE, j'ai DATEFACTURATION IS NOT NULL
- et cela ne fonctionnerait pas dans le select non plus
- et cela ne fonctionnerait pas non plus sur ma base en Oracle 8

Une autre idée ?

[pascalT]

Apres avoir creusé un peu (beaucoup), je pense que l'erreur vient du WHERE.

DATEFACTURATION IS NOT NULL ne semble pas exécuté avant le TO_DATE(...
Effectivement, dans ce cas là, ca pause soucis.
Je sais que je peux eviter d'avoir des valeurs nulles en utilisant la fonction NVL, mais je devrais mettre une valeur par défaut dans ce cas...et je ne peux pas (le résultat de la requete serait faux à certaines périodes).
Le plan d'éxécution de la requete est donc différent entre Oracle 8 et 10g.

Comment puis-je m'assurer que mon 1er WHERE soit exécuté avant le TO_Date(... ?

[McM]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
WITH t AS (SELECT TO_DATE(NULL) AS dtenulle FROM dual)
SELECT 1
FROM t
WHERE dtenulle IS NOT NULL
AND TO_DATE(TO_CHAR(dtenulle,'DD/MM') || '/2007','DD/MM/YYYY') > SYSDATE

ORA-01858 a non-numeric character was found where a numeric was expected

Les conditions WHERE sont toutes vérifiées en même temps (donc datefacturation peut être null).
Donc c'est tout a fait normal que ça marche dans ton select.
Bref,

- dans mon WHERE, j'ai DATEFACTURATION IS NOT NULL

Fallait le dire au début, pô bien de cacher des infos

[pascalT]

Pourquoi ma requete fonctionnait tres bien avant en Oracle 8 ?
Il y a un paramétrage pour éviter ce genre de chose ?

[salim11]

Salut,

Essaie d'éliminer les nulls avant c'est a dire dans ta clause from
Essaie ce code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SQL> WITH t AS (SELECT TO_DATE(NULL) AS dtenulle FROM dual)
  2  SELECT 1
  3  FROM ( SELECT * FROM  t WHERE dtenulle IS NOT NULL) T
  4  WHERE  TO_DATE(TO_CHAR(dtenulle,'DD/MM') || '/2007','DD/MM/YYYY') 
> SYSDATE;

aucune ligne sélectionnée

[pascalT]

Je suis entierement d'accord avec toi pour la requete.
Maintenant, ce que je voudrez comprendre, c'est pourquoi ce genre de requete fonctionnait en Oracle8 et ne fonctionne plus en Oracle10g. Cela me permettrait de mieux détecter les problèmes dans le cadre de ma migration.
Merci

[laurentschneider]

Je suis entierement d'accord avec toi pour la requete.
Maintenant, ce que je voudrez comprendre, c'est pourquoi ce genre de requete fonctionnait en Oracle8 et ne fonctionne plus en Oracle10g.

je ne suis pas du tout d'accord avec la requête. Le fait que la requête fonctionne une fois ne veut pas dire que le code soit robuste. Il ne s'agit pas là de version mais bien de stabilité.

en effet, la sous-requête peut être fusionée avec la requête principale par l'optimiseur, donc pas de chance dans ce cas.

le seul code que je considère comme bon est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
SELECT * FROM  t 
WHERE decode(dt,null,null, 
  TO_DATE(TO_CHAR(dt,'DD/MM') || '/2007','DD/MM/YYYY') 
  > SYSDATE;

Là on est vraiment sûr que le to_date ne sera pas executé.

Bon bien sûr ca boggue quand dt=29/02/2004 !!!

[pascalT]

S'il ne s'agit pas de comportements différents à cause de la version, il s'agit bien de comportements différents entre les optimiseurs des 2 versions.
Quelles sont les différences principales des 2 optimiseurs ?
Sinon, comment puis-je savoir les différences des 2 optimiseurs ?

[laurentschneider]

Là n'est pas le problème... C'est vrai que si tu employais le RULE BASED optimizer en 8i et que tu employes maintenant le COST BASED, ça peut faire la différence. Avec le RULE BASED, le plan pour une requête était constant. Avec le CBO, ça ne marche plus, le plan peut changer à tout moment, selon les statistiques etc...

Quoi que même en RBO, ça tient du miracle que ta requête n'ait jamais planté

[pascalT]

Merci de ta réponse Laurent, je venais de découvrir aussi ta réponse.
Y a t-il un moyen de passer (temporairement même si cela n'est pas propre) une base 10g en RBO ?

[pascalT]

Je viens de trouver la réponse à ma question.
Un petit ALTER SESSION suffit.
Merci à tous de votre aide

[abibes]

Bonjour,

J'ai le même problème (ORA-01858), mais c'est un peu spécial.
Je m'explique:

Je dois insérer plusieurs milliers de lignes dans la base avec python (cx_Oracle), et donc j'ai voulu utiliser la méthode cursor.executemany (query, param).
Mais lorsque j'execute mon scripte, il me sort cette erreur (ORA-01858: a non-numeric character was found where a numeric was expected),
alors que (ce que je n'ai pas encore compris), lorsque j'insère ligne par ligne, eh bien ça marche.

Voici le bout de code (une table de test):

Creation table:
CREATE TABLE MKT_DATA.test
(
name VARCHAR2(20),
dt DATE
)

Python qui marche:
cursor.execute("INSERT INTO MKT_DATA.TEST_MEHDI(NAME,DT) VALUES('mon_nom',TO_DATE('2008-08-13','YYYY-MM-DD'))")

Python qui NE marche PAS:
cursor.executemany("INSERT INTO MKT_DATA.TEST_MEHDI(NAME,DT) VALUES(:NAME,T)",[('mon_nom', "TO_DATE('2008-08-13','YYYY-MM-DD')")])

j'ai même essayé:
cursor.execute("INSERT INTO MKT_DATA.TEST_MEHDI(NAME,DT) VALUES(:NAME,T)",[('mon_nom', "TO_DATE('2008-08-13','YYYY-MM-DD')")])

Mais, MEME problème.

Pouvez-vous m'aider la dessus?

Merci d'avance

[ste78]

cursor.executemany("INSERT INTO MKT_DATA.TEST_MEHDI(NAME,DT) VALUES(:NAME,T)",[('mon_nom', "TO_DATE('2008-08-13','YYYY-MM-DD')")])

Salut,
tu as essayé sans les guillemets ?

[abibes]

Je ne peux pas, puisque python cherchera la méthode TO_DATE, et il ne trouveras pas...

Merci quand même.