SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Row-By-Row Processing Without Cursor


Row-By-Row Processing Without Cursor

Author
Message
Amin Sobati
Amin Sobati
SSC Rookie
SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)SSC Rookie (43 reputation)

Group: General Forum Members
Points: 43 Visits: 1
Comments posted here are about the content posted at temp
Martijn Melenhorst
Martijn Melenhorst
Grasshopper
Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)

Group: General Forum Members
Points: 15 Visits: 1
Just wondering: How fast is string-processing really in SQL Server (2005)? If I inserted 5000 records at once, would building up this string really be faster than just using a cursor?
shashi kant
shashi kant
SSC-Addicted
SSC-Addicted (482 reputation)SSC-Addicted (482 reputation)SSC-Addicted (482 reputation)SSC-Addicted (482 reputation)SSC-Addicted (482 reputation)SSC-Addicted (482 reputation)SSC-Addicted (482 reputation)SSC-Addicted (482 reputation)

Group: General Forum Members
Points: 482 Visits: 557

I don't think that this row by row operation could really help some one ..
because this code does not give the clear view of row by row operation ...

Instand of using this thing u can use the Table variable while loop which help lot compare to Cursor...

Here is the Logic.....
--Create a Table Variable and Variable Counter

DECLARE @InitialTable TABLE(RowNo INT IDENTITY(1,1) NOT NULL PRIMARY KEY CLUSTERED, Field1 int, Field2 Int)
DECLARE @IncrementalCounter INT 'This variable is declare for Loop

--All values are inserted into Your Table Variable ........
Insert into @InitialTable (field1, Feld2)
Select A1, A2 from Your_Table Where Your_Condition
----------------------------------------------------------
--Initialize the Counter
SET @IncrementalCounter = 1
--Condition of Checking the No of records to be traverse
while @IncrementalCounter <= ISNULL((SELECT COUNT(RowNo) FROM @InitialTable),0)
BEGIN
--Here we set the variable value to the @variable
SELECT @Variable = Field1 FROM @InitalTable where RowNo = @IncrementalCounter

SET @IncrementalCounter = @incrementalCounter +1
END


Kevin O'Donovan
Kevin O'Donovan
SSC Veteran
SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)

Group: General Forum Members
Points: 231 Visits: 84
Better still, rewrite usp_Process to optionally accept tabular data, either via a table variable or XML. Okay, not always possible, but when it is it will be far more efficient than repeated calls to the stored procedure



dreel
dreel
Grasshopper
Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)

Group: General Forum Members
Points: 15 Visits: 1
How can it work on the Select?
There's no any trigger to proccess SELECTs.
david rawheiser
david rawheiser
Grasshopper
Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)Grasshopper (22 reputation)

Group: General Forum Members
Points: 22 Visits: 29
Of course, dynamic SQL assumes a level of security that we may not want to enable.

The alternative is a traditional procedural while loop, when set operations can not be designed up front.
Tim Chapman-218780
Tim Chapman-218780
Old Hand
Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)

Group: General Forum Members
Points: 337 Visits: 115
Anyone know if SQL Server plans on designing triggers in the future to include the FOR EACH ROW clause like they do in Oracle that allows you to treat your trigger as if you are dealing with atomic values, rather than a data set?
Taconvino
Taconvino
SSC Rookie
SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)SSC Rookie (27 reputation)

Group: General Forum Members
Points: 27 Visits: 16
Another "we all hate cursors" article... I have to agree with Martijn's post on this one. Cursors, table variables, temporary tables, and so on... they are tools to be used on certain situations. We shouldn't disregard an option because "it's just bad". Cursors have their use, even if it is to write a non-critical, very small (in terms of data processing) procedure easily.
Tim Chapman-218780
Tim Chapman-218780
Old Hand
Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)Old Hand (337 reputation)

Group: General Forum Members
Points: 337 Visits: 115
I agree with that. We use cursors a lot, not for iterating through result sets and performing operations on the data with normal cursors, but for executing business rules. Here is an article some may find interesting that details how we execute dynamic business rules... http://articles.techrepublic.com.com/5100-9592_11-6123199.html
Kevin O'Donovan
Kevin O'Donovan
SSC Veteran
SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)SSC Veteran (231 reputation)

Group: General Forum Members
Points: 231 Visits: 84
> Another "we all hate cursors" article

Not necessarilly. I'm not disputing that cursors have their uses, and when you need one then you need one. However it's certainly worth being aware of the cost, and particularly so when writing a trigger. I don't think I'd recommend the route that the author described, as I think it could hide the fact that the real cost is in executing a complex operation n seperate times, and the cost of the cursor is small in comparison. I've certainly come across code like that. However if it's in a time critical piece of code (and unless I knew unequivocably otherwise I'd automatically assume this applied to a trigger) I'd devote some effort to making the stored procedure (to use the example in the article) accept a set of input items and process them in a single pass.



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search