You know how sp_MSforeachtable
is undocumented, and may go away at any time/be modified?
Well, if you’re happy to ignore that, it has another parameter called @whereand
, which is appended to the WHERE
clause of the internal query that is being used to find the tables (and should start with an AND
).
You also have to know that there’s an alias, o
against sysobjects
, and a second alias syso
against sys.all_objects
.
Using this knowledge, you might craft your @whereand
parameter as:
EXEC sp_MSforeachtable
@command1='...',
@whereand='AND o.id in (select object_id from sys.columns c where c.name=""EMP_CODE'')'
You can now also simplify your command1
, since you know it will only be run against tables containing an EMP_CODE
column. I’d probably take out the COUNT(*)
condition also, since I don’t see what value it’s adding.
Updated based on your further work, and tested against one table:
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="''+@EMPCODE+'''
IF @COUNT>0
BEGIN
PRINT PARSENAME("?",1)+'' => ''+CONVERT(VARCHAR,@COUNT)+'' ROW(S)''
--PRINT ''DELETE FROM ''+PARSENAME("?",1)+'' WHERE EMP_CODE='''''+@EMPCODE+'''''''
END
'
EXEC sp_MSforeachtable
@command1=@sql,@whereand='AND O.ID IN (SELECT OBJECT_ID FROM SYS.COLUMNS C WHERE C.NAME=''EMP_CODE'')'
(I’ve reverted the @whereand
to query for EMP_CODE
, since you don’t want to replace the value there).
The issue is that, you can pass parameters to a stored procedure, or literals, but you can’t perform calculations/combining actions between them – so I moved the construction of the sql statement out into a separate action.