script sql et passage de paramètres

Sous oracle 10g

J'ai un souci avec un script sql auquel je passe des paramètres, dans ce script j'ai ce genre de commande :

Code:

---

1 2	grant SELECT on TABLE_CONSTRAINTS to ROL_&5_TOTO;

---

où &5 est le 5ème paramètre passé au script.

Il s'avère que quand le script passe sur cette commande, il repasse en mode interactif et réclame &5 et supprime la fin de la commande (après &5), d'où plantage.

Comment remédier à ce pb sans passer par un execute immediate ?

Cordialement.

Bonsoir

Dans un environnement SQL*Plus standard, le caractère & signale le début du nom d'une variable (positionnelle ou de substitution).
Mais il faut aussi un moyen d'identifier la fin de ce nom.

Certains caractères sont considérés comme des terminateurs implicites du nom de la variable. Outre le saut de ligne et l'espace, on peut citer :
; / \ : *

Mais le tiret de soulignement (_) ne fait pas partie de ces terminateurs implicites. Dans votre cas, cela signifie que "&5_TOTO" est considéré comme le nom d'une variable.
Il faut alors utiliser un moyen explicite pour indiquer que votre variable s'arrête à 5. C'est justement le rôle du caractère de concaténation, qui, par défaut, est le point.

Code:

---

1 2	SQL> show concat concat "." (hex 2e)

---

Si vous transformez votre commande comme suit, tout rentrera dans l'ordre.

Code:

---

1 2	grant SELECT on TABLE_CONSTRAINTS to ROL_&5._TOTO;

---

Contrairement aux terminateurs implicites, qui sont affichés tels quels, l'opérateur de concaténation est "muet" : il n'apparaît pas à l'affichage.

Si l'on veut concaténer une variable avec un point, il faut donc doubler le point. Le premier représente l'opérateur de concaténation, alors que le second a sa pleine valeur de caractère affichable.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SQL> set VERIFY ON SQL> define SCHEMA=SYSTEM SQL> define TABLE=TEST SQL> select count(*) from &SCHEMA..&TABLE; ancien 1 : select count(*) from &SCHEMA..&TABLE nouveau 1 : select count(*) from SYSTEM.TEST COUNT(*) ------- 9

---

Merci beaucoup !!!!!!!!!!!!!
Faut-il préciser en début de script :

Code:

---

1 2 3

SHOW concat concat "." (hex 2e)

---

Bon, j'essaierai avec/sans pour voir ce qui marche.

Je pensais que || était la concaténation.

Merci encore.

PS : J'ai aussi dans mon scriptsql paramétré, des commandes du type :

Code:

---

update cd_fdw_structure set table_name=upper('ROL_&1._INT_TMP') where object_type='APPLICATION_ROLE' and standard_custom='S' and table_name like upper('ROL_%_TMP') and table_name<>upper('ROL_&1._INT_TMP');

---

où le paramètre &1 est entre '', j'ai l'impression en voyant défilé les commandes à l'écran (script appelé par un .bat) qu'il ne remplace pas le paramètre &1. par la bonne valeur mais par la valeur 1.

Me trompé-je ?

Cordialement.

Normalement ça marche :

Code:

---

1 2 3 4 5 6 7 8 9

SQL> SELECT TABLE_NAME FROM USER_TABLES WHERE TABLE_NAME = 'TEST&1._TMP'; Entrez une valeur pour 1 : 2 ancien 1 : SELECT TABLE_NAME FROM USER_TABLES WHERE TABLE_NAME = 'TEST&1._TMP'   nouveau 1 : SELECT TABLE_NAME FROM USER_TABLES WHERE TABLE_NAME = 'TEST2_TMP'   TABLE_NAME ------------------------------ TEST2_TMP

---

ok c'est bon !

En fait c'est pas tout à fait bon, dans un script le passage du paramètre se passe mal, dans un fichier trace du script j'ai ça :

Code:

---

1 2 3

ancien 1 : update cd_fdw_structure set table_name=upper('ROL_&1._REP_RO') where object_type='APPLICATION_ROLE' and standard_custom='S' and table_name like upper('ROL_%_REP_RO') and table_name<>upper('ROL_&1._REP_RO') nouveau 1 : update cd_fdw_structure set table_name=upper('ROL_1_REP_RO') where object_type='APPLICATION_ROLE' and standard_custom='S' and table_name like upper('ROL_%_REP_RO') and table_name<>upper('ROL_1_REP_RO')

---

Il remplace &1. par '1' au lieu de la valeur passée.

Y a-t-il des commandes oracle dans un script qui font perdre la valeur des paramètres passés ? (déconnexion, ...).

Bizarre, bizarre, dans la plupart des cas la substitution des paramètres se passe bien.

Il y a surement quelque chose qui m'échappe !

Cordialement.

bon je crois que j'ai un début de réponse, ce script appelle à son tour d'autres scripts en leur passant des paramètres, au retour de l'appel de ces scripts les paramètres initiaux (passés au script principal) auraient changé et pris les valeurs des paramètres passés aux scripts "secondaires" appelés. Faudrait peut-être passer par des variables globales renseignées dès le début du script pour ne pas perdre leurs valeurs. On va essayer ça !!

Bon c'est effectivement ce que je craignais, Oracle se paume entre les paramètres en entrée du script et les paramètres des scripts appelés par le script principal, ex :

toto = 1;
tata = 2;
titi = 3;

scriptPrincipal toto tata titi;
@script2nd1 0 3
@script2nd2 0 1

Au retour de script2nd2, toto (=&1) vaut 0 et tata (=&2) vaut 1.

Eh oui.........