La raison pour laquelle cela ne fonctionne pas est que @P1 est traité comme une valeur unique.
par exemple. lorsque @Code est X101,B202, la requête est simplement exécutée en tant que:SELECT * FROM Table WHERE RegionCode IN ('X101,B202') Ainsi, il recherche un RegionCode avec la valeur contenue dans @P1. Même lorsque vous incluez des guillemets simples, cela signifie simplement que la valeur recherchée dans RegionCode devrait contenir ces guillemets simples.
Vous devez en fait concaténer la variable @Code dans le texte de la commande @Cmd sql pour qu'elle fonctionne comme vous le pensez :
SET @Code = '''X101'',''B202'''
SET @Cmd = 'SELECT * FROM Table WHERE RegionCode IN (' + @Code + ')'
EXECUTE (@Cmd)
Évidemment, cela ne fait que vous ouvrir à l'injection SQL, vous devez donc être très prudent si vous adoptez cette approche pour vous assurer de vous protéger contre cela.
Il existe d'autres moyens de gérer cette situation où vous souhaitez transmettre une liste dynamique de valeurs à rechercher.
Découvrez les exemples sur mon blog pour 2 approches que vous pouvez utiliser avec SQL Server 2005. L'une consiste à transmettre une liste CSV sous la forme "Valeur1,Valeur2,Valeur3" que vous divisez ensuite en une variable TABLE à l'aide d'une fonction définie par l'utilisateur (il y a beaucoup de mentions à ce sujet approche si vous effectuez une recherche rapide sur Google ou sur ce site). Une fois divisé, vous joignez ensuite cette variable TABLE à votre requête principale. La deuxième approche consiste à transmettre un objet blob XML contenant les valeurs et à utiliser la fonctionnalité XML intégrée de SQL Server. Ces deux approches sont démontrées avec des métriques de performances dans ce lien, et elles ne nécessitent aucun SQL dynamique.
Si vous utilisiez SQL Server 2008, les paramètres de valeur de table seraient la solution - c'est la troisième approche que je démontre dans ce lien qui ressort le mieux.
