Limite du Sql? Exec, mais après?

Voici mon problème.
Les Exec j'arrive à le faire, c'est simple et pratique, mais j'ai besoin de "mieux" :roll:

J'aurais aimé pouvoir faire quelque chose de ce genre:

Code:

---

1 2 3 4

DECLARE @Matable VarChar(250) SET @Matable = 'tTable' SELECT * FROM @Matable

---

Mais quand je fais ça, j'ai une belle erreur du genre

Citation:

---

Server: Msg 137, Level 15, State 2, Line 3
Must declare the variable '@Matable'.

---

J'ai aussi essayé avec [@Matable] mais ça ne fonctionne pas (même genre d'erreur).

Vous me direz peut être "mais pourquoi vouloir utiliser ce principe" ?
Pour un curseur que je veux "dynamique", car le curseur n'accepte pas d'être défini avec un ordre Exec.
Bref c'est pour éviter de créer 80 procédures stockées qui auraient le même code à l'interne sauf les noms de table qui changent...

Je sais qu'avec Windev par exemple j'arrive à faire exécuter dynamiquement un code contenu dans une chaine... donc en principe c'est possible.

Ma question est : peut on le faire en sql server, si oui comment, si non: y a t'il une autre méthode?
Le but étant d'éviter de créer 80 procédures qui font le même travail à un détail près (ce détail étant le nom de la table)...

Merci d'avance.

Code:

---

1 2 3 4 5 6

DECLARE @Matable VarChar(250) DECLARE @Marequete VarChar(250) SET @Matable = 'INVENTORY' Set @Marequete = 'SELECT * FROM ' + @Matable EXEC(@Marequete)

---

Sans doute, est ce cette formule que tu ne veux pas employer puisque je fais usage de EXEC...

Pour la déclaration d'un curseur, ça ne fonctionnera pas car j'ai déjà testé avec un exec du genre "EXEC SELECT * FROM maTable" et ça donnait une erreur comme quoi il n'attendait pas un exec par ici.

Sinon j'ai peut être une solution temporaire... créer une table temporaire résultant d'un exec, et ensuite libérer les ressources de la table temporaire, mais est-ce que c'est possible, je me demande bien si "@matable=exec..." fonctionnerait.

Quelqu'un aurait une solution?

La définition d'un curseur avec l'ordre EXEC est totalement possible. Je te donne un petit exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

SET @query ='DECLARE Tempo_Cursor CURSOR FOR SELECT DISTINCT ch1,ch2,ch3,ch4 FROM '+@cheminTabTempo+' WHERE clauses' --print @query --Déclaration du curseur de sélection des lignes à traiter EXECUTE(@query) IF @@ERROR <>0 RETURN -1   --Ouverture du curseur OPEN Tempo_Cursor     --Lecture ere ligne du curseur FETCH NEXT FROM Tempo_Cursor INTO @ch1,@ch2,@ch3,@ch4 --Boucle sur le curseur WHILE @@FETCH_STATUS = 0   FETCH NEXT FROM Tempo_Cursor INTO @ch1,@ch2,@ch3,@ch4 END CLOSE Tempo_Cursor DEALLOCATE Tempo_Cursor

---

J'utilise cette manière d'opérer dans toutes mes procédures stockées et je n'ai aucun soucis.

N'hésite pas si tu veux plus d'infos

J'utilisais une méthode différente :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

DECLARE curseur_parcours CURSOR FOR SELECT Activite_ID FROM tActivite ORDER BY Ordre OPEN curseur_parcours FETCH curseur_parcours INTO @id WHILE @@FETCH_STATUS = 0 BEGIN SET @increment_courant = @increment_courant + @increment UPDATE tActivite SET Ordre = @increment_courant WHERE Activite_ID = @id FETCH curseur_parcours INTO @id END CLOSE curseur_parcours DEALLOCATE curseur_parcours

---

Et quand je testais pour mettre l'exec, je le mettais juste après le FOR.

Je n'avais pas vu ce mode d'utilisation de curseur que tu proposes, je pensais qu'il fallait toujours donner un FOR pour définir un curseur.

Ta solution fonctionnera donc surement dans mon cas! MERCI :king: