Vous savez comment sp_MSforeachtable
est sans papiers et peut disparaître à tout moment/être modifié ?
Eh bien, si vous êtes heureux d'ignorer cela, il a un autre paramètre appelé @whereand
, qui est ajouté à WHERE
clause de la requête interne qui est utilisée pour trouver les tables (et doit commencer par un AND
).
Vous devez également savoir qu'il existe un alias, o
contre sysobjects
, et un second alias syso
contre sys.all_objects
.
En utilisant ces connaissances, vous pourriez créer votre @whereand
paramètre comme :
EXEC sp_MSforeachtable
@command1='...',
@whereand='AND o.id in (select object_id from sys.columns c where c.name=''EMP_CODE'')'
Vous pouvez désormais également simplifier votre command1
, puisque vous savez qu'il ne sera exécuté que sur des tables contenant un EMP_CODE
colonne. Je retirerais probablement le COUNT(*)
condition aussi, puisque je ne vois pas quelle valeur cela ajoute.
Mis à jour en fonction de vos travaux ultérieurs et testé par rapport à un tableau :
DECLARE @EMPCODE AS VARCHAR(20)
SET @EMPCODE='HO081'
declare @sql nvarchar(2000)
set @sql = '
DECLARE @COUNT AS INT
SELECT @COUNT=COUNT(*) FROM ? WHERE EMP_CODE='''[email protected]+'''
IF @COUNT>0
BEGIN
PRINT PARSENAME("?",1)+'' => ''+CONVERT(VARCHAR,@COUNT)+'' ROW(S)''
--PRINT ''DELETE FROM ''+PARSENAME("?",1)+'' WHERE EMP_CODE='''''[email protected]+'''''''
END
'
EXEC sp_MSforeachtable
@[email protected],@whereand='AND O.ID IN (SELECT OBJECT_ID FROM SYS.COLUMNS C WHERE C.NAME=''EMP_CODE'')'
(J'ai inversé le @whereand
pour interroger EMP_CODE
, puisque vous ne voulez pas y remplacer la valeur).
Le problème est que vous pouvez passer des paramètres à une procédure stockée, ou littéraux , mais vous ne pouvez pas effectuer de calculs/combinaison d'actions entre eux - j'ai donc déplacé la construction de l'instruction sql dans une action distincte.