August 22, 2010 at 1:49 pm
Ninja's_RGR'us (8/22/2010)
Here's a weird idea, start worrying about it when you plan to move to sql 201? and having the upgrade advisor throwing errors and warnings.In the mean time I never used tlename.colname so I won't lose too much sleep over this :w00t: and I'm pretty sure you shouldn't have to either!
Nice advice but misplaced a bit, Remi. The only reason I worry about this is because a lot of other people make code the wrong way, IMHO. If or when this happens, there's going to be a bazillion pieces of code that need to be fixed by those people. I'd rather help people figure that out now rather than when it's too late... especially when some people keep telling other people how to write code the wrong way... IMHO. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
August 22, 2010 at 2:03 pm
I see your point. My own pers. favorite has always been to use table aliases and using it on the columns, even with only 1 table in the query. And since that can't possibly be depreciated in the forseeable future, I can go back to my nap ;-).
Happy googling.
August 22, 2010 at 2:19 pm
Jeff Moden (8/21/2010)
GilaMonster (8/20/2010)
Jeff Moden (8/20/2010)
Comment withdrawn. I couldn't find the MS reference that I remember seeing to support what I said so I've withdrawn my comment.Now I'm curious... PM or email?
Nah... it's ok. I'm embarassed but it's nothing I can't post.
I was referring to using actual table names as part of 2 part notation in the SELECT list. I remember very clearly seeing something from MS about code like the following not being supported at some future date...
SELECT tablename.columnname1,
tablename.columnname2
FROM dbo.tablename
The thing I read (and can no longer find) said that you should either use just the column name (obviously not recommended when joins are present) or to use an alias for the table name to be used in the SELECT list columns as many of us currently do.
The closest thing I can find in the deprecation lists is the fact that you won't be able to use 3 and 4 part naming in the SELECT list in the future, but I can't find the part about the 2 part naming. The MS link I'm talking about (and can no longer find) had the 2 part nuance of all that clearly explained.
Of course, that "find" happened when I was on some serious meds for Bronchitis so it may have been a manifestation on my part. :hehe:
I recall the same thing - and I don't have the reference either. But, it is related to how you write your queries. In SQL Server 2005 and above, MS now recommends that you always schema qualify object access.
If you schema qualify the table, then try to use the tablename.column syntax - that doesn't work. Without an alias, you would have to use 3-part naming (or 4-part for linked servers) - which, of course, is being deprecated.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
August 22, 2010 at 2:31 pm
Jeffrey Williams-493691 (8/22/2010)
I recall the same thing - and I don't have the reference either. But, it is related to how you write your queries. In SQL Server 2005 and above, MS now recommends that you always schema qualify object access.If you schema qualify the table, then try to use the tablename.column syntax - that doesn't work. Without an alias, you would have to use 3-part naming (or 4-part for linked servers) - which, of course, is being deprecated.
That matches my recollection, so it's a combination of 3-part naming of column been deprecated and schema-qualifying being recommended, not that 2-part naming of columns is deprecated.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 22, 2010 at 2:38 pm
Ninja's_RGR'us (8/22/2010)
Here's a weird idea, start worrying about it when you plan to move to sql 201? and having the upgrade advisor throwing errors and warnings.
In addition to Jeff's point, it's also the nagging irritation of having read something but not been able to recall it completely. :hehe:
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 22, 2010 at 4:42 pm
GilaMonster (8/22/2010)
Ninja's_RGR'us (8/22/2010)
Here's a weird idea, start worrying about it when you plan to move to sql 201? and having the upgrade advisor throwing errors and warnings.In addition to Jeff's point, it's also the nagging irritation of having read something but not been able to recall it completely. :hehe:
Been there done that. I've since gone on a low information diet.... learn / research something only if it's going to immediately help you get something done on your important todo list.
It's been a real eye opener as well as productivity booster.
Anyhow, I know you'll still google your socks off tonight so happy googling :-P.
August 22, 2010 at 4:58 pm
Ninja's_RGR'us (8/22/2010)
Anyhow, I know you'll still google your socks off tonight so happy googling :-P.
Nah, mainly because I can't think of a search term that'll get me a result without a million useless hits to wade through.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 22, 2010 at 5:20 pm
Ninja's_RGR'us (8/22/2010)
I see your point. My own pers. favorite has always been to use table aliases and using it on the columns, even with only 1 table in the query. And since that can't possibly be depreciated in the forseeable future, I can go back to my nap ;-).
I absolutely agree with that... even the 1 table alias.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 22, 2010 at 5:27 pm
GilaMonster (8/22/2010)
Jeffrey Williams-493691 (8/22/2010)
I recall the same thing - and I don't have the reference either. But, it is related to how you write your queries. In SQL Server 2005 and above, MS now recommends that you always schema qualify object access.If you schema qualify the table, then try to use the tablename.column syntax - that doesn't work. Without an alias, you would have to use 3-part naming (or 4-part for linked servers) - which, of course, is being deprecated.
That matches my recollection, so it's a combination of 3-part naming of column been deprecated and schema-qualifying being recommended, not that 2-part naming of columns is deprecated.
That's a good idea and logically true... but the article I read (and can't find) very specifically said that two part naming in the SELECT list where the first part was a table name was being deprecated and wouldn't actually work at some point in the future. Lordy, I wish I could find that article.
As Remi said, I don't use table names in the SELECT list to begin with so it's not a personal problem for me. I just wish I could find the article so I could justify telling folks not to do it.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 22, 2010 at 5:39 pm
Just use the "do what I say" line... seems to work for many people.
Leave the rest to fie and ask for our help when they screw up... :w00t:
August 22, 2010 at 7:05 pm
Heh... I'm one of those people that hate the "just do what I say" line. That's a 6 pork chop offense in my book.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 22, 2010 at 7:21 pm
And we know that Jeff doesn't want any pork chops aimed at him! :w00t:
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
August 22, 2010 at 7:27 pm
WayneS (8/22/2010)
And we know that Jeff doesn't want any pork chops aimed at him! :w00t:
Z'actly. I'm busy enough launching them. I don't have time to watch for incoming. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 13 posts - 16 through 27 (of 27 total)
You must be logged in to reply to this topic. Login to reply