Problème de variable lors de l'appel d'un fichier sql

Bonjour à tous,

Voilà un petit problème à vous soumettre :

J'ai un fichier sql, contenant une requête qui devra être appelée par plusieurs shells.

Cette requête contient des variables.

Ex: select * from table where champ = $var

Dans les shells, je dois "envoyer" cette requête dans un pipe, puis l'exécuter.

Le problème est que je n'arrive pas à remplacer les variables par leur valeur, déclarée dans le shell avant d'envoyer la requête dans le pipe.

J'espère que vous pourrez m'aider :)

Merci d'avance,

Nicolas

probablement en faisant un truc du genre :

Code:

---

echo "commande sql "$valeur" where ..... "$variable" ; " | interpreteurSQL

---

exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$ unset toto ; unset titi $ toto=20 $ titi=gazoil $ echo "select * from "$titi" where ref >= "$toto" ; " | mysql -u francois -p perso -h undertaker Enter password: ref date prix km 20 2011-07-03 39.83 564 21 2011-08-01 56.26 716 22 2011-08-27 54.85 722 23 2011-09-17 46.7 581 24 2011-10-09 55.4 708 25 2011-11-01 58.47 718 26 2011-11-29 57.74 691 $ $ $ unset toto ; unset titi

---

Ça c'est exactement ce que je faisais avant. Mais là, j'essaie de séparer la requête et le Shell.

Fichier.sql
Fichier.sh

Comment :
1. Déclarer les variables
2. Appeller le fichier sql pour que les variables dans la requête soient bien remplacées par leur valeur.

J'espère que c'est plus clair :)

En gros :

fichier.sql

Code:

---

1 2	select ch1, ch2, ch3 from $table where champ1 = $champ

---

fichier.sh

Code:

---

1 2 3 4 5

table=personnes champ=Paul   . fichier.sql | mysql -u francois -p perso -h undertaker

---

Bonjour,

Le contenu des fichiers lus n'est pas sujet au développement des variables. Désolé.

une solution : utiliser un fichier patron, le modifier avec sed, avec les variables ad'hoc, vers un fichier temporaire, et utiliser ce fichier temporaire, ou utiliser la sortie de sed
...
?

Arf! Il me semblait bien que ce n'était pas si simple... :)

Pour vous donner une idée du contexte, j'ai plusieurs shells différents qui doivent tourner sur des DB différentes mais de même structure, mais qui doivent exécuter la même requête à un moment ou l'autre, avec des variables différentes. Les shells sont sujets à modification, la requête aussi, mais je n'ai pas envie de devoir éditer une dizaine de shells à chaque fois que la requête change...L'idée d'avoir un fichier sql séparé, c'est surtout pour pouvoir éditer la requête dans un éditeur adhoc avec un highlight correct de la syntaxe.

Et si je fais quelque chose comme ceci, puisque si je ne me trompe, si on appelle un shell et non un fichier txt ou sql, les variables passent...

fichier01.sql

Code:

---

1 2	select ch1, ch2, ch3 from $table where champ1 = $champ

---

fichierquer.sh

Code:

---

1 2 3 4 5 6 7

QUER() { echo "echo"" . fichier$sql.sql echo """ }

---

monshell.sh

Code:

---

1 2 3 4 5 6

export sql=01 export table=personnes export champ=Paul . fichierquer.sh QUER | mysql -u francois -p perso -h undertaker

---

Une autre idée serait de commenter le la partie echo " dans le fichier sql, puis de renommer le fichier sql en sh et retirer les caractères de commentaire, inclure le fichier sh puis le buter. Faisable?

Merci d'avance,

-N

tu ne peux pas sourcer un fichier de commandes sql dans un interpréteur de commandes : il ne va pas comprendre le contenu du fichier tel qu'il le devrait être.

Damned! Je suis donc fait comme un rat...

Il ne me reste plus qu'à faire des .sh contenant les requêtes... Mais j'avoue que ça ne me plait pas des masses :)

Et si je crée un shell qui construit un shell temporaire contenant la requête, puis qui l'efface après que je l'ai appelé dans mon shell d'origine?

utilise une fonction :

Code:

---

1 2 3 4 5 6

maBelleFonctionSQL() { sql="$1" table="$2" champ="$3" mysql -u francois -p perso -h undertaker -e "select ch1, ch2, ch3 from $table where champ1 = $champ" }

---

et plus loin :

Code:

---

maBelleFonctionSQL 01 personnes Paul

---

sachant que les arguments passés ici à la fonction peuvent être des paramètres positionnels du script…

Citation:

---

Envoyé par N_BaH

utilise une fonction :

Code:

---

1 2 3 4 5 6

maBelleFonctionSQL() { sql="$1" table="$2" champ="$3" mysql -u francois -p perso -h undertaker -e "select ch1, ch2, ch3 from $table where champ1 = $champ" }

---

---

Salut

J'ai pas tout lu en détail (peut-être aurais-je du) mais à quoi sert la variable "sql" de ta fonction ???

Ou plus simple: pourquoi copier des variables dans d'autres ???

Code:

---

1 2 3

maBelleFonctionSQL() { mysql -u francois -p perso -h undertaker -e "select ch1, ch2, ch3 from $2 where champ1 = $3" }

---

Je ne demanderai pas pourquoi écrire une fonction qui ne fait qu'une ligne plutôt que d'appeler direct la ligne mais je t'assure que j'en ai très envie...:aie:

Citation:

---

à quoi sert la variable "sql"

---

aucune idée. Je reprend les termes de la question.

Citation:

---

pourquoi copier des variables dans d'autres ?

---

pour montrer ce qui se passe; ce n'est évidemment pas nécessaire.

Citation:

---

pourquoi écrire une fonction qui ne fait qu'une ligne plutôt que d'appeler direct la ligne

---

parce que, à ce que j'ai compris (eomer n'est pas très clair), la commande doit être appelée avec différents arguments.

Je vais essayer de clarifier alors :)

J'ai :
- 10 bases de données
- une vingtaine de shells
- une vingtaine de requêtes

Plusieurs shells différents peuvent appeler les mêmes requêtes, ou inversement un shell peut utiliser plusieurs requêtes différentes en fonction de ce que j'ai besoin de faire.

L'idée, pour "simplifier" et organiser tout ça, est de séparer les requêtes des shells, histoire de ne pas finir avec plusieurs centaines de shells, et de pouvoir faire un changement éventuel à un seul emplacement, dans un seul fichier.

Un dossier contenant les shells, et un contenant les requêtes. La difficulté vient de ce que j'aimerais avoir les requêtes dans des fichiers blabla.sql (extension qui me permet de les modifier dans un éditeur ad hoc, avec un highlight de la syntaxe. Ces requêtes sont relativement longues (jusqu'à une dizaine de join en tout genre, et au moins autant de variables).

Comment dans un shell, appeler un fichier sql, et exécuter la requête tout en ayant remplacé les variables par leur valeur...

J'espère que c'est plus clair :)

Je n'ai aucun problème par contre, à passer par un shell intermédiaire qui transformerait le fichier sql en fichier sh par exemple.

Dans les posts plus haut, la variable $sql servait à identifier le bon fichier sql :)

Citation:

---

Envoyé par eomer

Je vais essayer de clarifier alors :)

J'ai :
- 10 bases de données
- une vingtaine de shells
- une vingtaine de requêtes

Plusieurs shells différents peuvent appeler les mêmes requêtes, ou inversement un shell peut utiliser plusieurs requêtes différentes en fonction de ce que j'ai besoin de faire.

L'idée, pour "simplifier" et organiser tout ça, est de séparer les requêtes des shells, histoire de ne pas finir avec plusieurs centaines de shells, et de pouvoir faire un changement éventuel à un seul emplacement, dans un seul fichier.

Un dossier contenant les shells, et un contenant les requêtes. La difficulté vient de ce que j'aimerais avoir les requêtes dans des fichiers blabla.sql (extension qui me permet de les modifier dans un éditeur ad hoc, avec un highlight de la syntaxe. Ces requêtes sont relativement longues (jusqu'à une dizaine de join en tout genre, et au moins autant de variables).

Comment dans un shell, appeler un fichier sql, et exécuter la requête tout en ayant remplacé les variables par leur valeur...

J'espère que c'est plus clair :)

Je n'ai aucun problème par contre, à passer par un shell intermédiaire qui transformerait le fichier sql en fichier sh par exemple.

---

Mouais. En fait tu cherches à séparer les choses. Un peu comme en MVC...

Bon, à la base, il n'y a rien qui t'interdise de donner une extension ".sql" à un script shell. C'est pas super propre mais c'est permis. Ca pourrait donc te simplifier certaines choses. Tu pourrais par exemple intégrer la fonction de N_BaH dans tes scripts "sql" que tu appellerais depuis ton shell. Ou mieux, tu peux écrire tes fonctions shells dans des scripts ".sql" que tu sourceras dans tes scripts shells. Ainsi ces derniers connaitront lesdites fonctions qu'ils pourront appeler.
Exemple
toto.sql

Code:

---

1 2 3 4 5 6

maBelleFonctionSQL() { sql="$1" table="$2" champ="$3" mysql -u francois -p perso -h undertaker -e "select ch1, ch2, ch3 from $table where champ1 = $champ" }

---

script_principal.sh

Code:

---

1 2 3

source toto.sql maBelleFonctionSQL 01 personnes Paul

---

Toutefois cela reste pas super propre. Un ".sql" étant sensé contenir une requête et non un script.

Autre possibilité: envoyer directement tes fichiers sql dans mysql. Après-tout, mysql attend une requête. Que cette requête vienne d'un echo ou d'un fichier, quelle importance ???
Exemple:
toto.sql

Code:

---

select ch1, ch2, ch3 from table where champ1 = valeur;

---

script.sh

Code:

---

cat toto.sql |mysql -u francois -p perso -h undertaker

---

Citation:

---

Envoyé par eomer

Dans les posts plus haut, la variable $sql servait à identifier le bon fichier sql :)

---

Ouais. Bon ben avec mon exemple cela devient presque inutile. Enfin l'important est d'arriver à construire l'idée. Ensuite, que tu la traduises par des strings en dur ou par des variables...

Toutefois je ne vois pas trop comment créer des sql avec des variables. Tu parles d'éditeur highligh donc je présume qu'il s'agit d'un éditeur sql. Donc qui demande une syntaxe sql. Et dans ce genre de syntaxe, il n'y a pas de place pour des variables...
Ou alors tu écris ton propre interpréteur.
1) des fichiers sql écrits dans une syntaxe propriétaire intégrant la notion de variable
Exemple
toto.sql

Code:

---

select %1 from %2 where %3

---

2) un programme chargé de convertir le sql propriétaire en sql standard

Code:

---

traducteur.sh toto.sql "ch1, ch2, ch3" "table" "champ1 = valeur" |mysql -u francois -p perso -h undertaker

---

Le programme "traducteur.sh" étant de ton fait et prenant en compte toto.sql "ch1, ch2, ch3" "table" "champ1 = valeur" pour générer la string
"select ch1, ch2, ch3 from table where champ1 = valeur;". Toutefois, pour ce travail, je conseillerais un langage un poil plus puissant que le shell (comme par exemple Python)...

Question bête mais je ne vois pas la précision qui me semble primordiale pour le pb en question...
C'est une base de quel éditeur ?
Oracle ?
DB2 ?
SQLServer ?
etc...

Il y a bien des réponses avec MySql mais le propriétaire du post ne mentionne rien à ce sujet...

Autant avec Oracle et du shell Unix/Linux je le fais sans pb autant en DB2 il me semble que ce n'est pas possible, ou alors en générant un fichier sql dynamiquement via le shell...
Cordialement

C'est une base Sybase IQ :)

Mais personnellement, je ne pense pas que cela change grand chose... Le noeud du problème c'est de savoir comment je pourrais appeler un fichier sql dans un shell, tout en lui passant les variables avant de l'exécuter.

Je remets les mains dedans demain matin... et je vais tester deux ou trois trucs :)

Un script sql avec des parametre identifiable ex : ==P1== ==P2== ...
et un petit sed ,awk ou autre pour traduire avant le pipe ...

Oui en gros mon "sql dynamique" généré via un script :lol:

@eomer: si il y a une importance, sous DB2 il est possible de lancer un .sql mais pas de lui passer un paramètre me semble t-il, j'ai cherché pas mal de temps sans trouver sur un projet pour me rabattre sur du sql dynamiquement généré.
Sous Oracle je le fais couramment et Sybase je ne connais pas...

Au passage je viens de voir qu'il était possible de placer "d'accord" / "pas d'accord" mais au minimum pour faire avancer le "chmilblique" ceux qui placent des "pas d'accord" donnez vos solutions! C'est un forum d'entraide ou je me suis gouré ???

+1 , d'accord avec toi, les votes devraient etre publiquement nominatifs ( ils le sont "secretement" déjà puisqu'on peut ensuite changer de vote ... )

faudrait surtout qu'il soit justifiés par un petit texte genre 100 caractères ... pour pouvoir "voter" en justifiant par "inapproprié/hors sujet/faux/super idée/parfait/merci/etc...etc..."