script SQL oracle et caractère "&"

Mardi 12 octobre 2004 à 13:58 GMT, Lionel a écrit :

Bonjour,

Bonsoir,

J'ai un problème avec mes échanges de script SQL avec un admin oracle.
Tous les "&" contenus dans le script sont interprétés comme des indicateurs
de commande.
Il me semble qu'il y a une commande à exécuter qui permet d'ignorer les "&".
Quelqu'un connait-il cette commande ?

Sous SQL*Plus, SET DEFINE OFF va empêcher l'interprétation du &.
Il y a aussi SET ESCAPE qui permet d'utiliser le (ou autre car.) en
tant que caractère de protection, ce qui vous permettra d'avoir 'A&B'
sans que le & soit interprété.

J'ai également un problème avec les caractères accentués.
Avec l'ancien admin, il n'y avait aucun problème, mais depuis qu'il a
changé, tous les caractères accentués sont transformés lors du lancement du
script d'insertion de données.
Puis-je forcer le charset dans mon script SQL pour qu'il n'y ait plus
d'erreur ?

Vous pouvez exporter la variable d'environnement NLS_LANG avant de
lancer sqlplus, ou la définir / modifier en cours de route par
ALTER SESSION SET NLS_LANGUAGE = French_France.ISO8859P15 par ex.

Dernière question: l'admin ne devrait pas effecuter ces vérifications lui
même avant de lancer mon script ?

Euh... Joker !
--
Th. Thomas.

'lut,

La meilleure solution serait de remplacer ce caractère réservé comme
suit :

select * from toto where champ='TTT&1' par :

select * from toto where champ='TTT'||chr(38)||'1';

Pour les accents le nls_lang, et au niveau OS, il faut vérifier les
variables LC_???? et LANG. Mais sur certains OS, non UTF8 ou
accentophobe, il y a par moment des problèmes. Quand j'en ai marre, je
remplace par les chr qui vont bien. cf la table des caractères
standards.

C'est bourrin je sais, mais cela marche toujours.

Cdlt,


Olivier


"Lionel" <SPAMcoollATfreePOINTfr> wrote in message news:<416be315$0$6463$626a14ce@news.free.fr>...

Bonjour,

J'ai un problème avec mes échanges de script SQL avec un admin oracle.
Tous les "&" contenus dans le script sont interprétés comme des indicateurs
de commande.
Il me semble qu'il y a une commande à exécuter qui permet d'ignorer les "&".
Quelqu'un connait-il cette commande ?

J'ai également un problème avec les caractères accentués.
Avec l'ancien admin, il n'y avait aucun problème, mais depuis qu'il a
changé, tous les caractères accentués sont transformés lors du lancement du
script d'insertion de données.
Puis-je forcer le charset dans mon script SQL pour qu'il n'y ait plus
d'erreur ?

Dernière question: l'admin ne devrait pas effecuter ces vérifications lui
même avant de lancer mon script ?

Merci d'avance...

Lio

Olivier Guyot wrote:

'lut,

La meilleure solution serait de remplacer ce caractère réservé comme
suit :

select * from toto where champ='TTT&1' par :

select * from toto where champ='TTT'||chr(38)||'1';

C'est le lancement de mon script via sql plus qui pose problème.
insert into maTable (champ1) values ('toi & moi');
Le dba n'arrive pas à l'exécuter à cause des &.
Si je les vire dans mon fichier, aucun souci, mais c'est moyen comme
solution.

Pour les accents le nls_lang, et au niveau OS, il faut vérifier les
variables LC_???? et LANG.

Quand j'insère un accent via mon appli java ca fonctionne.
Quand le "DBA" (stagiaire ??) lance mes scripts, ça plante tous les
caractères accentués.
C'est pas la base qui pose problème, c'est le dba, et sa façon de lancer mes
scripts.
Aucun souci sur les meme scripts lancés avec Toad dans ma base.
Puis-je conseiller à mon "dba" d'utiliser toad car sinon il n'y arrivera
jamais ?

Thierry Thomas wrote:

Sous SQL*Plus, SET DEFINE OFF va empêcher l'interprétation du &.

Parfait, c'est ce que je cherchais !
Merci.

Vous pouvez exporter la variable d'environnement NLS_LANG avant de
lancer sqlplus, ou la définir / modifier en cours de route par
ALTER SESSION SET NLS_LANGUAGE = French_France.ISO8859P15 par ex.

Pour pas prendre de risque là prochaine fois je dirai à l'admin de se
démerder pour que les accents soient récupérés.
C'est son job après tout.

Dernière question: l'admin ne devrait pas effecuter ces
vérifications lui même avant de lancer mon script ?

Euh... Joker !

:-)

Lionel wrote:

> Pour les accents le nls_lang, et au niveau OS, il faut vérifier les
> variables LC_???? et LANG.

Quand j'insère un accent via mon appli java ca fonctionne.
Quand le "DBA" (stagiaire ??) lance mes scripts, ça plante tous les
caractères accentués.
C'est pas la base qui pose problème, c'est le dba, et sa façon de lancer mes
scripts.
Aucun souci sur les meme scripts lancés avec Toad dans ma base.
Puis-je conseiller à mon "dba" d'utiliser toad car sinon il n'y arrivera
jamais ?

Le dba a peut être d'autres impératifs que vous. Le dba doit s'assurer
de garder une trace de l'ensemble des scripts qu'il exécute sur la base.
Il doit donc les conserver dans un emplacement centralisé (qui n'est
probablement pas son PC).

Le dba n'a peut être pas que votre application à gérer. Chaque
développeur effectue peut être ses développements dans des
environnements différents.

Le problème des caractères accentués n'est pas forcément simple à gérer.
Bien entendu, je suppose que vous ignorer (bien sûr) le character set
que vous utilisez pour écrire les scripts que vous donnez à votre dba.
Donc, bien évidemment, je suppose que vous balancez vos scripts à votre
dba sans aucune précision et accessoirement, peut être, en lui indiquant
que c'est urgent parce que vous n'avez pas été capable de livrer
correctement vos scripts du premier coup.

Le dba n'est pas devin, il ne peut pas deviner avec quel character set
vous lui livrez vos scripts. Peut être que les bases Oracle sont sur un
serveur Unix, peut être que vous travaillez sous Windows. Il faut alors
positionner correctement le character set dans la variable NLS_LANG
(afin qu'il utilise le character set de windows).

Bruno Jargot wrote:

Le dba a peut être d'autres impératifs que vous. Le dba doit s'assurer
de garder une trace de l'ensemble des scripts qu'il exécute sur la
base. Il doit donc les conserver dans un emplacement centralisé (qui
n'est probablement pas son PC).

Moi aussi je le fais.
Ne serait-ce que pour pouvoir les lancer en recette puis en prod.

Le dba n'a peut être pas que votre application à gérer.

Moi non plus je n'ai pas qu'une application à gérer.
Mais quand un client me demande de faire une modification, j'attends pas 4
jours et 5 relances pour lui dire qu'il va me falloir encore 5 jours parce
que je suis trop occupé pour lancer un script de 4 lignes en recette.

Chaque
développeur effectue peut être ses développements dans des
environnements différents.
Le problème des caractères accentués n'est pas forcément simple à
gérer. Bien entendu, je suppose que vous ignorer (bien sûr) le
character set que vous utilisez pour écrire les scripts que vous
donnez à votre dba. Donc, bien évidemment, je suppose que vous
balancez vos scripts à votre dba sans aucune précision et
accessoirement, peut être, en lui indiquant que c'est urgent parce
que vous n'avez pas été capable de livrer correctement vos scripts du
premier coup.

Mes scripts sont toujours parfaits du premier coup :-)
Et en général il lance mes script sans jamais prévenir personne, ni attendre
le feu vert de ses collèges admin websphere, ce qui me cause parfois des
problèmes.
Et m'oblige à faire un nouveau script pour corriger ces problèmes, alors que
j'avais prévenu qu'il fallait couper l'accès à l'appli tant que tout était
pas à jour.

Le dba n'est pas devin, il ne peut pas deviner avec quel character set
vous lui livrez vos scripts. Peut être que les bases Oracle sont sur
un serveur Unix, peut être que vous travaillez sous Windows. Il faut
alors positionner correctement le character set dans la variable
NLS_LANG (afin qu'il utilise le character set de windows).

Là je suis bien d'accord.
Je lui fournirai le fichier dans le bon charset la prochaine fois.
Mais un dba expérimenté et soucieux de son travail demanderait le charset
avant, non ?
Et quid du "set define off", qu'il devrait pourtant connaitre ?
En lisant les logs d'erreurs, il aurait compris en 2 secondes l'origine du
problème.

Lionel wrote:

Mes scripts sont toujours parfaits du premier coup :-)

Ce n'est pas crédible ;-)

Bruno Jargot wrote:

> Le dba n'est pas devin, il ne peut pas deviner avec quel character set
> vous lui livrez vos scripts. Peut être que les bases Oracle sont sur
> un serveur Unix, peut être que vous travaillez sous Windows. Il faut
> alors positionner correctement le character set dans la variable
> NLS_LANG (afin qu'il utilise le character set de windows).

Là je suis bien d'accord.
Je lui fournirai le fichier dans le bon charset la prochaine fois.
Mais un dba expérimenté et soucieux de son travail demanderait le charset
avant, non ?

hum ...
Je me considère comme un dba expérimenté soucieux de mon travail et je
me suis déjà fait avoir par ces p* de caractères accentués. Il n'est pas
forcément courant que les scripts de mises en production intègrent des
accents. Ce sont généralement les fichiers de données qui contiennent
des accents et l'intégration de ces fichiers n'est généralement pas
manuelle.

La première fois que j'ai été confronté à ce problème est dans le cadre
d'une application avec ... Websphere. La compréhension profonde du
problème m'a alors pris un certain temps.

Après, il faut se mettre d'accord sur le codage des fichiers. Juste une
question de dialogue pour trouver la solution la moins contraignante
pour tout le monde.

Et quid du "set define off", qu'il devrait pourtant connaitre ?

connaitre, pas forcément. Mais il doit être capable de trouver la
solution très rapidement.

En lisant les logs d'erreurs, il aurait compris en 2 secondes l'origine du
problème.

oui à condition qu'il ne soit pas submergé par des tonnes de logs. Mais
il aurait du vérifier la présence des erreurs oracle.