Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Executing a print statement for each row in a result set pretty much requires a cursor or an approach similar to this</p> <pre><code>declare @id int, @stuff varchar(20) declare @tmp table ( id int not null , stuff varchar(20) primary key(id) ) insert @tmp select id, stuff from mastertable where condition1 &gt; condition2 select top 1 @id=id, @stuff=stuff from @tmp while (@@rowcount &gt; 0) begin print @stuff delete from @tmp where id=@id select top 1 @id=id, @stuff=stuff from @tmp end </code></pre> <p>You are still looping thru each row, but you avoid a cursor. Since you are using a table var you instead of a cursor you avoid table locking, but this is not necessarily a better approach. You can process row by row in a variety of possible ways such as adding an "processed column" or numbering all of the selected rows 1..n and iterating based on the rownumber</p> <p>You can only avoid row by row processing if you can perform a set-based operation. There is not enough information in your question to see if this is avoidable in TSQL</p> <p>Now, writing a CLR proc may be more flexible as you have a much richer programming model, and there is little overhead to looping through each row of the result set within the CLR proc. Making a database call from the CLR proc for each row that a database call from each row in TSQL</p> <p>EDIT - I see someone already added one possible way to convert you print statements into a set oriented operation. i.e.</p> <pre><code>declare @msg varchar(max) select @msg = '' select msg = @msg + stuff from mastertable where condition1 &gt; condition2 print @msg </code></pre> <p>This is OK, in fact optimal what I was referring to when I said performing a set operation. A set based operation is always preferred when possible . It may not be obvious, but string concatenation can also get very slow in this example too if many rows are involved.</p> <hr /> <p>I said that using a temp var avoids table locking. This is not precisely true as sql server does write temp vars to a table in tempdb. What I really meant was that you avoid locking a production table and since you are guaranteed to be the only user of this table, you don't compete for concurrent access.</p> <p>I also made no attempt to make optimize this. For example, the inner loop could track the id and the where condition becomes where id>@id (you will also want a primary key defined on id). Since the temp table is not updated during each loop iteration I would expect it to be faster.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload