Problème d'espaces dans une requête SQL

Bonjour tout le monde, j'ai un petit soucis de requete SQL, je m'explique.

Actuellement j'ai un programme qui se connecte à une base de données oracle 9i.

J'ai dupliquer la base à l'identique sur un autre serveur oracle 9i.

Le soucis c'est que lorsque j'exécute mon programme en me connectant sur le deuxième serveur, les requêtes qui passaient sur le premier, échoues maintenant misérablement.

Par exemple :

[...] WHERE id=0ORDER BY id desc

(pas d'espacement entre le 0 et le ORDER)

ma question est donc :

Y a t il un paramètre de configuration qui permet à oracle de vérifier la syntaxe et d'ajouter automatiquement des espaces entre deux tokens?

merchi!

non il n'y a pas de paramètre pour qu'Oracle devine ce qu'il fallait écrire.
"Dupliquer une base sur un autre serveur Oracle" tu peux expliquer stp.

Désolé c'est la premiere fois que j'installe et que je configure un serveur oracle.

La duplication de la base est réalisé avec un fichier de dump.

Sous toad, en me connectant sur la premiere base, j'arrive a executer cette requete (je la met en complet, mais seul l'élément souligné pose problème):

SELECT TA_TYP_ETAT_OPE.TOPE_LIB, TA_OPERATION.OPE_DT_DEB_THEO, TA_OPERATION.OPE_DT_FIN_THEO, TA_ORDRE.ORD_ID, TA_ORDRE.ORD_NUM, TA_OPERATION.OPE_ID, TA_OPERATION.OPE_GAMME, TA_FIC_ART.FART_REF, TA_FIC_ART.FART_DESIGN, TA_OPERATION.TYP_TOPE_ID, TA_ARTICLE.ART_QTE_THEO, TA_ATELIER.ATE_LIB, TA_OPERATION.OPE_DT_DEB_THEO, TA_ARTICLE.ART_NUM_LOT FROM TA_OPERATION, TA_TYP_ETAT_OPE, TA_ORDRE, TA_ARTICLE, TA_FIC_ART, TA_ATELIER WHERE TA_OPERATION.TYP_TOPE_ID = TA_TYP_ETAT_OPE.TOPE_ID AND TA_OPERATION.ORD_ORD_ID = TA_ORDRE.ORD_ID AND TA_ORDRE.ORD_ID = TA_ARTICLE.ORD_ORD_ID AND TA_ARTICLE.FART_REF = TA_FIC_ART.FART_REF AND TA_OPERATION.ATE_ATE_ID = TA_ATELIER.ATE_ID AND (TA_OPERATION.OPE_DT_FIN is null OR to_date(TA_OPERATION.OPE_DT_FIN, 'dd/mm/yyyy') > '07/04/2008') AND (TA_ARTICLE.ART_FAB_BL = 1) AND (TA_ATELIER.ATE_ID = '71') AND TA_OPERATION.TYP_TOPE_ID = 1ORDER BY TA_OPERATION.OPE_DT_ACT

mais cette meme requete renvoit une erreur ORA-01722 lorsque je l'execute sur le second.

La solution serait de mettre un espace ou des ', cependant, je n'ai pas le droit de toucher à la requete, uniquement à la configuration du serveur.

Ta requête est fausse, tu veux qu'on y fasse quoi ?

En gros tu vas chez peugeot et tu leur dit un truc du style : "Voilà j'ai cassé le moteur de ma voiture mais il faut que je la démarre sans changer celui-ci et surtout sans que quiconque ouvre le capot..."

Tu as raison,

Mais je suis pas con non plus, si ca tenait qu'a moi, ca fait longtemps que j'aurais réécris la requête sans vous casser les couilles avec ma question débile, mais j'ai des contraintes imposées.

En production je suis en 9.2 et en qualification je suis en 9.0. La seule solution est donc de basculer en 9.2 pour la qualification, et supputer qu'entre la version 9.0 et 9.2 il y a eu un changement dans le parser SQL qui est devenu plus souple. C'est ca?

Merci.

Un peu de retenue s.v.p...

Le seul moyen de savoir si le parser permet ce genre d'annerie en 9.0 est de faire un test basique en SQL*Plus sur chacune des deux machines et de voir le résultat.

A contrario, la requête est fausse et la question de savoir si oui ou non le moteur permet ceci ou cela est de faire un retour SQL H.S vers les développeurs qui sont dans l'obligation d'écrire du code SQL propre. Et cela quelle que soit la société et/ou le rôle des développeurs !

Dans tous les cas, même si il existait un paramétrage miracle permettant de faire du SQL approximatif, cela serait totalement intolérable d'un point de vue professionnel.

Bref bats toi et joue ton rôle de DBA !

Désolé pour mon manque de retenue, mais mon énervement n'ai en aucun cas dirigé contre vous.

Quoiqu'il en soit, je vais aller pousser une gueulante dans le bureau du patron.

Le proverbe shadockien qui sied bien à ma situation : "pourquoi faire simple lorsqu'on peut faire compliqué"

Merci de votre aide en tout cas :)

Bye bye

Seule chose à retenir : Tu es un DBA donc tu as des responsabilités liées à ta fonction. Tu as l'obligation de garantir l'intégrité des espaces de données qui te sont confiés (La colonne vertébrale de la société tout de même) et également des méthodes pour y accéder (Les logiciels tout pourris qui gravitent autour). Ton rôle impose un droit de sanction et ce que cela fasse plaisir ou non à qui que ce soit. La pérennité de l'information et la stabilisation de son évolution et de son maintien dans le temps sont généralement directement liés à l'espérance de vie de la société...

Normalement entre la dév, la prod, la qualif, la recette, etc ... les versions devraient toujours être les mêmes, ça éviterait déjà bien des soucis

Je viens de faire un test avec la requête suivante :

SELECT * FROM DBA_SEGMENTS WHERE HEADER_FILE = 1ORDER BY SEGMENT_NAME;

et elle fonctionne à mon grand étonnement parfaitement sur une base 9.2 mais aussi sur une 8.1.7.

N'as-tu pas plutôt un problème de NLS ou des données polluées dans ton champ ? Ton champ est bien un number, pas de problème lors de la création de cette table ? Sinon recrée la table !

Lis la note 470776.1 à ce sujet, il s'agit certainement d'un problème de NLS_NUMERIC_CHARACTERS lors de l'import des données.