September 29, 2006 at 6:44 am
Hello,
I've been checking some SPs and triggers in our database and found rather terrible things - row by row processing at its worst (commercial software, so we can't do anything with it ourselves).
I think most of these things could be brought to set-based processing, but I'm at a loss what to do with the fact, that the program requires in a certain operation unique datetime to be written into each row. While processing row by row, it is done this way in the procedure:
while exists (select * from sometable
where product = @product and warehouse = @warehouse and datum = @datum)
begin
waitfor delay '00:00:00.002'
select @datum = getdate()
end
(and then later UPDATE sometable SET datum = @datum, .....)
I suppose this is needed because we are using FIFO method. Is there a way to achieve something like that when doing set-based operation? I'm afraid there isn't... and so we'll be stuck with this monstrosity we have there now.
September 29, 2006 at 7:19 am
The only way I can think of is to use temp table/table variable to store the unique key of the selected records plus IDENTITY column and update datetime using the IDENTITY column value as a multiplier to add milliseconds to GETDATE()
If there is no unique key then
Far away is close at hand in the images of elsewhere.
Anon.
September 29, 2006 at 7:23 am
There is the triangular join way but the temp table will always be faster for larget data sets. So use David's solution.
September 29, 2006 at 7:54 am
Thanks for the replies, there is unique key for each row so I will consider that. I will not be writing the procedure myself, I just wanted to have some arguments before I have a talk with the authors.
September 30, 2006 at 10:20 am
You might also want to remember that the minimum resolution for the DateTime data type is 3 milliseconds, not 2 as posted in the original code.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 2:04 am
But for uniqueness it is 4.
ie add 3 or 4 milliseconds to 13 milliseconds and you will get 17 milliseconds for both
Far away is close at hand in the images of elsewhere.
Anon.
October 2, 2006 at 6:27 am
I stand corrected. Thanks David.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 2, 2006 at 6:57 am
Heck, I only found out when I experimented before my first post
There is always something in SQL to catch me out
Far away is close at hand in the images of elsewhere.
Anon.
October 2, 2006 at 7:18 am
I think you can include everyone else on the planet on that one David .
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply