Si vous devez itérer (*), utilisez la construction conçue pour le faire - le curseur . Très décrié, mais s'il exprime le plus clairement vos intentions, je vous dis de l'utiliser :
DECLARE @ID int
DECLARE IDs CURSOR LOCAL FOR select ID from SAMPLE where Name = @NameParameter
OPEN IDs
FETCH NEXT FROM IDs into @ID
WHILE @@FETCH_STATUS = 0
BEGIN
exec myproc @ID
FETCH NEXT FROM IDs into @ID
END
CLOSE IDs
DEALLOCATE IDs
(*) Cette réponse a reçu quelques votes positifs récemment, mais je pense que je devrais également incorporer mon commentaire d'origine ici et ajouter quelques conseils généraux :
En SQL, vous devriez généralement rechercher une solution basée sur des ensembles. L'ensemble du langage est orienté autour de solutions basées sur des ensembles, et (à son tour) l'optimiseur est orienté vers le bon fonctionnement des solutions basées sur des ensembles. De plus, les outils dont nous disposons pour ajuster l'optimiseur est également orienté ensemble - par ex. appliquer des index aux tables.
Il y en a quelques situations où l'itération est la meilleure approche. Celles-ci sont rares et peuvent être comparées aux règles de Jackson sur l'optimisation - ne le faites pas - et (pour les experts uniquement) ne le faites pas encore .
Vous feriez bien mieux d'essayer d'abord de formuler ce que vous voulez en termes d'ensemble de toutes les lignes à affecter - quel est le changement global à réaliser ? - puis essayez de formuler une requête qui encapsule cet objectif. Ce n'est que si la requête générée par cette opération ne fonctionne pas correctement (ou s'il existe un autre composant incapable de faire autre chose que de traiter chaque ligne individuellement) que vous devriez envisager itération.
