declarations
-
Comments posted to this topic are about the item declarations
Tom
-
Easy, thx
Thanks & Best Regards,
Hany Helmy
SQL Server Database Consultant -
Easy one if you remember Toms explanation of the previous QotD:
DECLARE @i INT = 0;
equals
DECLARE @i INT;
SET @i = 0;
Thanks for the question!
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP -
Koen Verbeeck (8/19/2014)
Easy one if you remember Toms explanation of the previous QotD:DECLARE @i INT = 0;
equals
DECLARE @i INT;
SET @i = 0;
Thanks for the question!
Agreed.
-
andy.brown (8/19/2014)
Koen Verbeeck (8/19/2014)
Easy one if you remember Toms explanation of the previous QotD:DECLARE @i INT = 0;
equals
DECLARE @i INT;
SET @i = 0;
Thanks for the question!
Agreed.
Thanks for the question, Tom. I genuinely appreciate the syntax that allows declaration and initial assignment, but this is proof that they're really separate. I hope I don't see code like this in production.
-
Good question, Tom. Thanks!
This is a good example of how things can go wrong when using this syntax.
---------------
Mel.
-
Thanks for the question Tom. It shows quite clearly why serious consideration should be given to avoid the combo declare/set syntax.
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn -
-
Nice question, Tom. Thanks.
I like this syntax, if it is used properly (and not in the way documented here). I work in SQL Server and in Sybase ASE, which does not have this syntax, which makes me appreciate it even more. It's a shame that BOL doesn't document this very well (unlike the rest of BOL, which is, of course, VERY complete;-)).
-
Unless you're running 2005 or older, in which case you'd have a nice little syntax error happening
-
Thank you, Tom, very interesting one.
As the old saying goes "everything has pros and cons", so any one see the "pros" side of it?
(I am kind of feeling now, its one of the stupid question from me)
ww; Raghu
--
The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart. -
Raghavendra Mudugal (8/19/2014)
Thank you, Tom, very interesting one.As the old saying goes "everything has pros and cons", so any one see the "pros" side of it?
(I am kind of feeling now, its one of the stupid question from me)
The pro is of course that if you put all the declarations combined with assignment in a non-repeated part of the stored procedure, trigger, or batch the assignments get executed exactly once, so the net effect is much the same as declaration with initialisation to a chosen value and this can quite useful for making the code easier to read (it reduces clutter).
Something that is often claimed as a plus for this is that it eliminates the possibility of uninitialised variables, but that's pure nonsense. It doesn't have the effect that adding initialisation to declarations in some other languages, specifically languages which have variable declarations without initialisation, since (scalar) variable declarations in T-SQL initialise the variable to NULL anyway: there no such thing as an uninitialised variable in T-SQL; thus the claim that it eliminates the uninitialised variable problem from T-SQL (which I've seen rather too often) is nonsense, don't be fooled into thinking that that imaginary effect is a plus of allowing combined declaration and assignment syntax as an abbreviation for a declaration plus a set statement.
edit: typos
Tom
-
Nice and easy one. Thanks Tom.
-
TomThomson (8/19/2014)
The pro is of course that if you put all the declarations combined with assignment in a non-repeated part of the stored procedure, trigger, or batch the assignments get executed exactly once, so the net effect is much the same as declaration with initialisation to a chosen value and this can quite useful for making the code easier to read (it reduces clutter).Thank you, Tom. When I came to know the in-line assignment types, I said, great as I did in VB.NET, now I can do in SQL too, probably, in future versions there will also be an option to mention ByVal or ByRef (like stuff) in procedure/function level....and slowing sql scripting will be taken over by OOPS concepts.
ww; Raghu
--
The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart. -
Raghavendra Mudugal (8/19/2014)
TomThomson (8/19/2014)
The pro is of course that if you put all the declarations combined with assignment in a non-repeated part of the stored procedure, trigger, or batch the assignments get executed exactly once, so the net effect is much the same as declaration with initialisation to a chosen value and this can quite useful for making the code easier to read (it reduces clutter).Thank you, Tom. When I came to know the in-line assignment types, I said, great as I did in VB.NET, now I can do in SQL too, probably, in future versions there will also be an option to mention ByVal or ByRef (like stuff) in procedure/function level....and slowing sql scripting will be taken over by OOPS concepts.
It would be something of a catastrophe if SQL adopted OOPS concepts - it would stand a serious risk of degenerating into an appallingly awful mess like C++, wrecking the concept of data abstraction, and making set-oriented queries impossible to write (requiring RBAR iterators). Of course if competent academics made an OOPS-ified version of SQL it might not suffer those catastrophes, but competent academics wouldn't get a lookin because ANSI and ISO are effectively dominated by players from the IT industry.
Tom
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply