October 29, 2010 at 2:49 am
Sorry, I'm afraid I don't understand the point of the question.
Is it a trick to fool you into thinking the += compound operator? Or perhaps a typo when += was intended (but the answer doesn't support that theory)?
If not, it's just an assignation...
I stared at it for a while trying to work out what it was I was supposed to be noticing, or solving, or realising, but nothing came to me.
Maybe there's some SQL Server behaviour here that is unexpected from database experience only, whereas coming from a C# background I would think differently by default?
October 29, 2010 at 2:57 am
I think the question author tried to confuse us with the syntax for compound operators
I think the question author CONFUSED himself with the syntax for compound operators, as you can realize from author explanation: mismatch "compound operators" and "unary operator".
October 29, 2010 at 6:18 am
Carlo Romagnano (10/29/2010)
I think the question author tried to confuse us with the syntax for compound operators
I think the question author CONFUSED himself with the syntax for compound operators, as you can realize from author explanation: mismatch "compound operators" and "unary operator".
Quite possibly, but it's only a few weeks since I helped a colleague who had stared at the exact same error for several hours without noticing the =+. Interestingly enough this was for string manipulation. One can't help but wonder what a unary plus means in the context of string manipulation. A unary minus for strings throws an error, thankfully!
October 29, 2010 at 7:03 am
Good question, and very good follow up discussion. Thanks to all.
October 29, 2010 at 7:05 am
Amusingly, any sequence of unary operators before an integer (as long as two dashes together are avoided) seems to be valid in TSQL:
DECLARE @a int
SET @a = -+~-+~-+~-+~-+~-+~21
SELECT @a AS A
Playing with these sequences of operators made me realise that there is a way of mimicking the prefix increment and decrement operators in TSQL.
SELECT @a AS a, @b-2 AS b, -~@a AS [++a], ~-@b AS [--b], -~@a - ~-@b AS [++a - --b]
These seems to work "as expected" across the entire range of valid integers except for the single case of the increment operator on the minimum possible value of the integer (i.e. -2147483648 for the data type int). Also, it doesn't work properly with the tinyint type as negative values are not allowed with this type.
SELECT ~-N AS [--N], N, -~N AS [++N]
FROM (
SELECT -2147483647 UNION ALL
SELECT -100 UNION ALL
SELECT 0 UNION ALL
SELECT 100 UNION ALL
SELECT 2147483646
) TestData(N)
UNION ALL
SELECT ~-N AS [--N], N, NULL
FROM (
SELECT 2147483647
) TestData(N)
This contribution is for interest only. I'm certainly not suggesting that anyone actually makes use of these in production code!
October 29, 2010 at 8:53 am
I hate to admit it, but I got distracted by the fact that the select contained "@a A". Thinking that this was too easy of a question made me guess that the A was some obscure way of applying an absolute value function, hence I was the one person that chose "0,21" for an answer. I hope it comes from infrequent selection of variables to display them and not from turning 60 this year.
Steve
October 29, 2010 at 9:39 am
Yes, I agree. The explanation is incorrect.
To further illustrate what is happening here, try substituting =+ with =-
My interpretation is that you are applying a positive modifier to a negative value,
which obviously results in a negative return. If you apply a negative modifier to a negative number, the result is positive.
will return +21 when b is -21
😉
October 29, 2010 at 9:45 am
Correct me if I'm wrong. It's the spacing that is throwing most people off.
@a =+ @b-2 is the same as @a = (+1) * @b-2
if i were to write this in my code I would format it as
@a = +@b
but i wouldn't do that since +1 times any number yields that same number
Note that they mention a pre-increment operator but they mean a Compound Operator. Also note Compound Operators are only availabe in SQL 2008. Writing @a += @b-2 would throw a syntex error in earlier version.
October 29, 2010 at 10:05 am
I too wonder if the intent was to make you think it was the compound "+=" operator that was added in SQL Server 2008. Then the results would be 0, -21.
But since there was no mention of SQL Server 2008 I assumed it wasn't.
October 29, 2010 at 11:39 am
Oh well, I lost a precious point on this one. The statement in question
looked so ridiculous that it made me think that there were 2 possibilities:
- either it was the author's intention to actually write it as is, perhaps to show how difficult it can be to debug the errors based on misplacing the order of typed characters
- it was a simple typo, and the += was intended
Unfortunately, I chose the second option and thus answered the question incorrectly. I don't consider it a bad question, but cannot say that I learned something from it either, because in reality, nobody can actually benefit from ever typing something like
when select @a = @b-2 does the trick.
Oleg
October 29, 2010 at 12:43 pm
Oleg Netchaev (10/29/2010)
Oh well, I lost a precious point on this one. The statement in questionlooked so ridiculous that it made me think that there were 2 possibilities:
- either it was the author's intention to actually write it as is, perhaps to show how difficult it can be to debug the errors based on misplacing the order of typed characters
- it was a simple typo, and the += was intended
Unfortunately, I chose the second option and thus answered the question incorrectly. I don't consider it a bad question, but cannot say that I learned something from it either, because in reality, nobody can actually benefit from ever typing something like
when select @a = @b-2 does the trick.
Oleg
No, but you can benefit from knowing that it's an easy to make mistake, and that SQL Server won't alert you to the problem.
October 30, 2010 at 5:52 am
Not only is the explanation wrong, as several people have pointed out, it is also uses somewhat outdated terminology and is maybe confused about which version of SQL it refers to. The term "positive operator" was used in BoL for SQL 2000, but from SQL 2005 on that term is not used , the operator is called "unary plus" (presumably because MS relised that the term "positive operator" would be likely to confuse people when applied to a copy or no-op operator); but the question is clearly trying to trap people into mistaking =+ for += (why else would the first answer option be exactly what would be seen if the query had had += instead of =+), and += first appeared in SQL 2008, not in SQL 2000.
Tom
October 31, 2010 at 6:10 pm
Good Question. and very good follow up threads by some members. it clears some lack of answer explanations.
October 31, 2010 at 9:46 pm
da-zero (10/29/2010)
Iulian -207023 (10/29/2010)
It still remains unknown to me why SQL Server ignores the + in =+ instead of giving a syntax error.
If I understand correctly, it is not actually a syntax error. As someone else stated, the plus is a unary operator: @a = (+@b). To put in perspective, if the statement was @a =- @b-2, then @a now becomes 21, essentially @a = - (-21).
Hope that helps.
EDIT: Sorry, didn't realise there were more posts that have already explained this. Ignore at your own will.
November 2, 2010 at 2:28 pm
Nice question
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 15 posts - 16 through 30 (of 31 total)
You must be logged in to reply to this topic. Login to reply