21

I would like to execute a stored procedure over each row in a set without using a cursor with something like this:

SELECT EXEC dbo.Sproc @Param1 = Table1.id
FROM Table1


I am using T-SQL in SQL Server 2005. I think this might be possible using a function, but I'd like to use a stored procedure if possible (company standards)

Andy Mikula
  • 16,796
  • 4
  • 32
  • 39
user58714
  • 213
  • 1
  • 2
  • 4

7 Answers7

23

Yes. If you have a column you can use within the table to mark the ones processed, you can use WHILE EXISTS:

DECLARE @Id int
WHILE EXISTS(SELECT * FROM Table1 WHERE Processed='N')
BEGIN
 SELECT Top 1 @Id = id from Table1 WHERE Procesed='N'
 EXEC dbo.Sproc @Id
 UPDATE Table1 SET Processed = 'Y' WHERE Id = @Id
END

Alternately, dump the ids into a temp table or table variable and delete when finished:

DECLARE @HoldTable table (Id int PRIMARY KEY)
DECLARE @Id int
INSERT INTO @HoldTable SELECT Id FROM Table1
WHILE EXISTS(SELECT * FROM @HoldTable)
BEGIN
 SELECT @Id = id from @HoldTable
 EXEC dbo.Sproc @Id
 DELETE FROM @HoldTable where Id = @Id
END
SQLBobScot
  • 694
  • 5
  • 20
Josef
  • 7,431
  • 3
  • 31
  • 33
  • 1
    Edited your second answer. You were selecting into @Id instead of @HoldTable and you had a where clause of `where processed='N'` but @HoldTable has no such column. The second option should now work. I'm hoping I understood your intention correctly. – kralco626 Feb 24 '15 at 19:51
16

If you're only using SQL Server 2005 or newer, don't care about backwards compatibility and can convert your code to be in a User-Defined Function (rather than a stored proc) then you can use the new "CROSS APPLY" operator, which does use a syntax very similar to what you want. I found here a short intro (of course, you can also read the BOLs and MSDN)

Supposing your SP returns a single value named out_int, your example could be rewritten as:

SELECT T.id, UDF.out_int
FROM 
    Table1 T
CROSS APPLY
    dbo.fn_My_UDF(T.id) AS UDF

This will retrieve each "id" from Table1 and use it to call fn_My_UDF, the result of which will appear in the final result-set besides the original parameter.

A variat of "CROSS APPLY" is "OUTER APPLY". They are equivalents of "INNER JOIN" and "LEFT JOIN", but work on joining a table and a UDF (and calling the second at the same time).

If you must (by explicit order of the pointy-haired boss) use SPs insead, well - bad luck! You'll have to keep with cursors, or try cheating a bit: change the code into UDFs, and create wrapper SPs :D.

Joe Pineda
  • 5,521
  • 3
  • 31
  • 40
  • CROSS APPLY does not work for Stored Procedures, as they do not return datasets, just report outputs. Functions return anything, so that's why SQL can only use them when using CROSS APPLY. Down voted. – Fandango68 Sep 19 '14 at 03:36
  • 15
    @Fernando68 I indicated 3 necessary conditions for using CROSS APPLY as a solution at the very beginning of my answer, 3rd of which is "can convert your code to be a UDF rather than SP" – Joe Pineda Oct 03 '14 at 15:47
  • how to use cross apply with stored procedure, since UDF cannot have exec command in its definition. – Abubakar Riaz Sep 17 '20 at 09:11
3

Frankly if I needed to execute a stored proc for a set of data instead if the one record it was written for , I would write the set-based code instead of using the stored proc. This is the only efficient way to do this if you are going to be running against a large data set. You could go from hours to do the insert that the stored proc does to seconds or even milliseconds. Do not use record based processing ever when you need to processs a set of data especially not for a silly reason like reuse of code. Performance trumps reuse of code.

HLGEM
  • 94,695
  • 15
  • 113
  • 186
  • There are some items where you absolutely *must* use cursors, though as with GOTOs the real need for them is really really small. Agree it's better to do set-based processing wherever it makes sense, but your "performance trumps reuse of code" is a bit extremist. – Joe Pineda Jan 25 '09 at 21:19
  • Since we are talking the differnce between minutes and milliseconds or hours and seconds (or minutes), I don't think it is extremist. Programmers who don't consider database performance over code reuse (particularly when it comes to using cursors) generally have very badly performing databases. – HLGEM Jan 30 '09 at 15:15
  • You are the one who said it was seconds vs. hours. In that strawman case who could argue? But if the difference is milliseconds vs. seconds or milliseconds vs. twice as many milliseconds, it depends. – stannius Jul 22 '10 at 20:36
  • It's hardly a strawman case, it is real life experience. I have fixed cursors that had that kind of improvement, especially on large data set inserts. – HLGEM Jul 22 '10 at 20:43
  • The problem with pulling the code out of the sproc and into inline set code, is that you may have multiple statements that you want to run for each row, and that you need to call from several different triggers. That's the whole point of encapsulation, is to reduce the amount of code, and centralize it for when you need to make changes to it. – eidylon Feb 25 '14 at 18:47
  • Encapsulation is not a good thing in database terms when it affects performance. It is way down the list of things you should care about in datbase developement. It is great for object-oriented code but does not work well in a database environment when it causes severe performance problems. You can re-write the proc to handle sets of data if you prefer. – HLGEM Feb 26 '14 at 14:54
2

9 out of 10 times you can do what you want without a cursor or a while loop. However, if you must use one, I have found that while loops tend to be faster.

Also if you do not want to delete or update the table, you can use something like this:

DECLARE @id [type]
SELECT @id = MIN([id]) FROM [table]
WHILE @id IS NOT NULL
BEGIN
    EXEC [sproc] @id
    SELECT @id = MIN([id]) FROM [table] WHERE [id] > @id
END
Y.B.
  • 3,526
  • 14
  • 24
BankZ
  • 2,204
  • 1
  • 12
  • 8
  • 1
    Is this entirely accurate? Can you order by id without specifying a group by clause? – Richard Collette Jun 25 '10 at 16:12
  • It doesn't work right. It doesn't stop after reading the max id. – Tony_Henrich Mar 31 '11 at 22:42
  • 2
    -1 Doesn't work. As Richard Collette said, the select syntax is broken. And if you fix the syntax, the while gets stuck in an infinite loop, as pointed out by Tony_Henrich). I've added an answer that has a working loop, but was slow in my experience. – Walter Stabosz Apr 17 '12 at 17:31
  • Put the exec at the top of the loop, then no need to check the condition twice (obviously you would need to select the id once before the loop). – Marc K Jun 12 '15 at 11:36
  • This could only work for specific scenario (auto incremented integer id) – evictednoise Dec 22 '16 at 08:10
1

If possible I'd write a second version of the stored proc that reads from a temp table.

If that's not possible than you're probably out of luck.

Joshua
  • 40,822
  • 8
  • 72
  • 132
1

Take a look at this answer using dynamic SQL. Here is what looks like based on your query.

DECLARE @TSQL NVARCHAR(MAX) = ''
SELECT @TSQL = @TSQL + N'EXEC dbo.Sproc ' + id + '; 
' -- To insert a line break
FROM Table1
EXEC sp_executesql @TSQL

This equals to the following if you PRINT @TSQL. Note that how the line break is inserted.

EXEC dbo.Sproc id1; 
EXEC dbo.Sproc id2; 
EXEC dbo.Sproc id3;
...

If you don't need a stored procedure, it can be easier. I once had a need to update a table based on each row (Code is the column name, and [Value] the value) from a view. Because the view is dynamic and returns different rows each time, and hence different column-value pairs. I re-wrote the query without using any stored procedure.

DECLARE @TSQL NVARCHAR(MAX), @Id VARCHAR(10) = 50

SELECT @TSQL = COALESCE(@TSQL + '''
,','') + Code + ' = ''' + [Value] 
FROM view
WHERE Id = @Id

SET @TSQL = N'UPDATE tableName
SET ' + @TSQL + ''' 
WHERE Id = ' + @Id
PRINT @TSQL
--EXEC SP_EXECUTESQL @TSQL

PRINT @TSQL:

UPDATE tableName
SET Discussed = 'Yes'
,Other = 'Blue'
,IntakeRating = 'H: < $25k'
,IntakeValueEstimate = '25'
,OpportunityDecision = 'Intake'
,Fee = '33 1/3'
,Fee2 = '40'
,IsManager = 'Yes' 
WHERE Id = 50
Weihui Guo
  • 3,669
  • 5
  • 34
  • 56
0

This loop works, but it was slow for my SP. I think the correct answer is by HLGEM, your best bet is to write a better bulk query.

DECLARE @id INT
SET @id = 0

DECLARE @max INT
SELECT TOP 1 @max = TableID
FROM dbo.Table
ORDER BY TableID desc

-- loop until BREAK
-- this is how you can perform a DO-WHILE loop in TSQL
WHILE (1 = 1) 
BEGIN
    SELECT      
        TOP 1 @id = TableID
        FROM dbo.Table
        WHERE TableID > @id 

    IF @id IS NOT NULL
    BEGIN        
        -- call you SP here
        PRINT @id        
    END

    -- break out of the loop once the max id has been reached
    IF @id = @max BREAK 
END
Walter Stabosz
  • 7,447
  • 5
  • 43
  • 75