March 10, 2020 at 12:00 am
Comments posted to this topic are about the item The Triple Update
March 10, 2020 at 7:48 am
Interesting, but I'd be wary of using it. In a multi-row update, the result is pretty much undefined, unless all the rows are updated to the same value. And in that case, there isn't much point in the approach anyway, unless you really want to confuse the reader...
March 10, 2020 at 7:57 am
Is this behaviour specific to SQL version? When run against my SQL 2012 environment, the variable is set to 1, but the table data remains unchanged
Edit: Forget that. User error - it does edit the row as expected
March 10, 2020 at 8:37 am
Interesting! Well done!
March 10, 2020 at 9:36 am
From the post:
Not sure where this is useful or why it's there, but if anyone uses this, let us know.
If you yabingle "quirky update", you'll find examples of its use - generally for doing things like running totals in the days before we had the windowing functions.
Is this behaviour specific to SQL version?
It's been around for aaaaages. It certainly pre-dates SQL 2012, as it was being used in speed phreak events in 2009 and earlier...
Thomas Rushton
blog: https://thelonedba.wordpress.com
March 10, 2020 at 10:25 am
nice question, thanks Steve
been using something similar to this to build running totals (before windowing functions) for many years...
____________________________________________
Space, the final frontier? not any more...
All limits henceforth are self-imposed.
“libera tute vulgaris ex”
March 10, 2020 at 11:45 am
Interesting, but I'd be wary of using it. In a multi-row update, the result is pretty much undefined, unless all the rows are updated to the same value. And in that case, there isn't much point in the approach anyway, unless you really want to confuse the reader...
Actually, it can be made to work quite reliably and is a tried and true, nasty fast method for doing missing data smears and running totals.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2020 at 11:48 am
From the post:
Not sure where this is useful or why it's there, but if anyone uses this, let us know.
If you yabingle "quirky update", you'll find examples of its use - generally for doing things like running totals in the days before we had the windowing functions.
coalesceuk wrote:Is this behaviour specific to SQL version?
It's been around for aaaaages. It certainly pre-dates SQL 2012, as it was being used in speed phreak events in 2009 and earlier...
Heh... I wonder how many people actually got this question right without having to run the code?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2020 at 12:04 pm
Heh... I wonder how many people actually got this question right without having to run the code?
I've been using a related technique to emulate STRING_AGG, so it wasn't that much of a leap. It's a very useful way to generate column lists from system views to use in automatically generated SQL.
March 10, 2020 at 12:10 pm
Jeff Moden wrote:Heh... I wonder how many people actually got this question right without having to run the code?
I've been using a related technique to emulate STRING_AGG, so it wasn't that much of a leap. It's a very useful way to generate column lists from system views to use in automatically generated SQL.
That too! And, following prescribed methods that MS doesn't seem to know about (according to Books Online, anyway), it's quite reliable for that, missing data smears, and other running calculations such as running totals and partitioned running totals. Like Thomas stated, it was what some people (including myself) used long before the finally got the Windowing Functions right in 2012.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2020 at 12:37 pm
Thomas Rushton wrote:From the post:
Not sure where this is useful or why it's there, but if anyone uses this, let us know.
If you yabingle "quirky update", you'll find examples of its use - generally for doing things like running totals in the days before we had the windowing functions.
coalesceuk wrote:Is this behaviour specific to SQL version?
It's been around for aaaaages. It certainly pre-dates SQL 2012, as it was being used in speed phreak events in 2009 and earlier...
Heh... I wonder how many people actually got this question right without having to run the code?
I looked at it and 'knew' the answer from something at the back of my mind. I still ran it to check though, does that count?
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
March 10, 2020 at 1:10 pm
Jeff Moden wrote:...
Heh... I wonder how many people actually got this question right without having to run the code?
Even I knew about quirky update and I'm only a lowly developer. Surprised Steve wasn't familiar, guess it's a bit niche.
You, good Sir, are neither "only" nor "lowly". 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2020 at 2:37 pm
I used this behavior
In both cases it saves you some time / code, since you have not to read the just updated table again (or assigning the variable first and use the variable in the update)
God is real, unless declared integer.
March 11, 2020 at 12:05 pm
This is fun code to test and try to get ones head around - in which orders are operators applied.
DECLARE @i INT=0;
UPDATE t SET @i = id = @i + 1
SELECT @i;
Sql Server blog: http://www.tsql.nu
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply