Utilisation d'une variable dans le WHERE d'une requête

Bonjour,

Je suis en train de créer une procédure stockée sous Firebird 1.5.

Je récupère le nom d'une table que je stocke dans une variable (:NOM_TABLE). Je récupère également le nom de la clé en passant par les tables RDB$INDICES et RDB$INDEX_SEGMENTS.

Maintenant je voudrais utiliser ces variables dans une requête pour avoir la valeur de la clé de la table trouvée :

SELECT :NOM_CLE FROM :NOM_TABLE INTO :VALEUR_CLE

Cette requête ne semble pas fonctionner, il y a une erreur au niveau du FROM.

Avez-vous une solution pour utiliser une variable dans une requête ?

Merci

La syntaxe du select est :

Code:

---

1 2 3 4 5 6

SELECT [TRANSACTION transaction] [DISTINCT | ALL] {* | <val> [, <val> …]} [INTO : var [, : var …]] FROM <tableref> [, <tableref> …] [WHERE <search_condition>]

---

INTO avant le FROM :wink:

le but principal de ma question est donc :
est ce que <val> et <tableref> peuvent être des variables (du style :var) ?

Of course !

Ce système permet de parser n'importe quoi, et dès lors que la requète finale est syntaxiquement et fonctionnellement correcte, il ne devrait pas y avoir de problème.

Le parse doit arriver au même résultat que si tu construisais dynamiquement ta requète genre (sous delphi)

Code:

---

MaQuery:='SELECT '+MaColonne+' FROM '+MaTable;

---

Je ne comprend pas bien ta réponse.

Quand je fais une requête du style

Code:

---

SELECT :NOM_INDEX FROM :NOM_TABLE;

---

Il me dit à compilation de ma procédure qu'il y a une erreur au niveau de :NOM_TABLE avec les ":". J'enlève donc les ":" mais après il ne connais pas la table NOM_TABLE.

J'ai également des problèmes au niveau du :NOM_INDEX. Je l'ai déclaré en temps que VARCHAR(30). Quand je debugge ma procedure, il remplace bien la valeur de la variable mais avec plein de blancs derrière. J'ai donc fait un TRIM(:NOM_INDEX) mais cela ne lui plait pas non plus.

Tu développes avec quel outil ?

je développe ma procedure stockée sous EMS Interbase/Firebird Manager.

Ca fait longtemps que je n'ai pas toché à interbase, mais si je me souviens bien, voilà ce que l'on peut te répondre:

on ne peut pas utiliser de variable en lieu et place d'un nom de table ou d'un nom de colonne dans une requete SQL dynamique.

On peut seulement y remplacer la valeur d'une constante par le nom d'une variable.

Ainsi je peux écrire:

Code:

---

1 2	SELECT nom, prenom FROM personnes WHERE age < :max_age

---

au lieu de

Code:

---

1 2	SELECT nom, prenom FROM personnes WHERE age < 200

---

Mais je ne peux pas par contre écrire:

Code:

---

1 2	SELECT :col_A, :col_B FROM :table_E WHERE age < 200

---

La solution proposée par qi130 est gérer le problème au moment de l'écriture de la requête, en concaténant les morceaux de requête adéquats:

Code:

---

1 2	" SELECT " + col_A + " , " + col_B + " FROM " + table_E + " WHERE age < 200 "

---

Mais cette solution n'est pas adaptée à l'écriture d'une procédure stockée qui exige de connaitre la requête au moment de la création de la procédure, et non au moment de son exécution.

Il faut donc trouver une autre solution pour ton problème :

- écrire toutes les requètes possible et sélectionner la bonne à l'exécution
- écrire une fonction utilsateur en C et concaténer le texte de la requete au moment de l'exécution de la fonction ( exécuter la requête par un appel SQL depuis le C ! )
- faire autrement.

On ne peut faire des les PS et trigger des requetes dynamiques (créés à la vollées).

En fait les requetes sont compilées ds la PS, ce qui augmente la vitesse d'exécution de celle ci.

Cependant dans fb1.5 il est maintenant possible de créer et d'interpréter une requete dynamique.

La commande est execute statement.

Cependant elle a de nombreuses limites en plus (des problemes connue du au requetes dynamique (moins performantes, plus difficile a optimiser et gérer (maintenance)).

On peut faire un

Code:

---

1 2	for execute statement MaChaine into :mavar1, :marvar2 do ....

---

On voit bien là la limite ce qui est dynamique se sont les noms des colonnes, le nom des tables mais il faudra qu'au final le résultat ait le même nombre de colonne que de variables INTO et de même type (ou transtypable).

Voilà donc celà peux dépanner. Mais pour les cas vraiment dynamique et complexe, soit il faut revoir la conception de la base soit le faire depuis un programme client.

Merci à vous :D , vous m'avez compris 8)

Je vais voir avec "execute statement" sinon je vais me rabattre vers un programme client.

Le "EXECUTE STATEMENT" fonctionne bien sauf que mon éditeur me met une erreur au niveau du "INTO" après. Ca passe quand même.