Saturday, September 02, 2006
I'm frightened - "A future version of SQL Server will disallow usage of '*' in functions and views."
I was playing with the BPA the other, Microsoft's Best Practices Analyzer for SQL Server 2000, on a client database and I noticed this warning:
Holy smokes - I don't know a single developer, good or bad, who doesn't need to use this from time to time yet MSFT is threatening to take it away? What bollocks, to borrow an Engish term that's not quite as offensive as the word I actually wanted to type. Who the heck is MSFT to tell me whether I can program using SELECT * or not?
Leave me alone, Microsoft, and let me code the way that I want to. I mean, of course SELECT columnName1, columnName2, etc... is a better way to code but it's just so laborious to require us to code that way every single time - so unpractical. I write lots and lots of stored procs/views/functions built on system/catalog/dynamic-management views and, for the most part, I use SELECT * because it's more maintanable. If MSFT changes the columns, pshaw - what do I care? SELECT * covers me. Take away SELECT * and I'm left changing my code with every hotfix and service pack.
Arrrgghhhhhhhhhh........................ Leave me alone and let me code.
In peace.
One or more objects is using SELECT * syntax! It is recommended to provide explicit column lists rather than relying on expansion of '*'. A future version of SQL Server will disallow usage of '*' in functions and views.
Holy smokes - I don't know a single developer, good or bad, who doesn't need to use this from time to time yet MSFT is threatening to take it away? What bollocks, to borrow an Engish term that's not quite as offensive as the word I actually wanted to type. Who the heck is MSFT to tell me whether I can program using SELECT * or not?
Leave me alone, Microsoft, and let me code the way that I want to. I mean, of course SELECT columnName1, columnName2, etc... is a better way to code but it's just so laborious to require us to code that way every single time - so unpractical. I write lots and lots of stored procs/views/functions built on system/catalog/dynamic-management views and, for the most part, I use SELECT * because it's more maintanable. If MSFT changes the columns, pshaw - what do I care? SELECT * covers me. Take away SELECT * and I'm left changing my code with every hotfix and service pack.
Arrrgghhhhhhhhhh........................ Leave me alone and let me code.
In peace.
Technorati Tags: Scott Whigham, Whigham, SQL Server, SQL Server 2005, SQL Server, Microsoft SQL Server
