Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««4,1294,1304,1314,1324,133»»»

Are the posted questions getting worse? Expand / Collapse
Author
Message
Posted Wednesday, September 18, 2013 1:43 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 1:27 PM
Points: 868, Visits: 7,505
Koen Verbeeck (9/18/2013)
Stefan Krzywicki (9/18/2013)
Am I wrong in saying we shouldn't be using
SELECT * INTO #A1 FROM Table

SELECT * INTO #B1 FROM #A1

in production code? #A1 & #B1 are also never defined explicitly.


With the INTO clause you don't need to define tables explcitly.
But I wouldn't say it's a clean way of writing code.


Yeah, not defining things explicitly bothers me.


--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
Post #1496108
Posted Wednesday, September 18, 2013 2:12 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 8:26 AM
Points: 10,381, Visits: 13,436
Stefan Krzywicki (9/18/2013)
Koen Verbeeck (9/18/2013)
Stefan Krzywicki (9/18/2013)
Am I wrong in saying we shouldn't be using
SELECT * INTO #A1 FROM Table

SELECT * INTO #B1 FROM #A1

in production code? #A1 & #B1 are also never defined explicitly.


With the INTO clause you don't need to define tables explcitly.
But I wouldn't say it's a clean way of writing code.


Yeah, not defining things explicitly bothers me.


I'm just trying to figure out why it isn't just:

Select * INTO #B1 from Table

I'm just assuming that there is some kind of processing on #A1 that you aren't showing.




Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #1496123
Posted Wednesday, September 18, 2013 5:47 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:21 PM
Points: 7,928, Visits: 9,653
Koen Verbeeck (9/18/2013)
Stefan Krzywicki (9/18/2013)
Am I wrong in saying we shouldn't be using
SELECT * INTO #A1 FROM Table

SELECT * INTO #B1 FROM #A1

in production code? #A1 & #B1 are also never defined explicitly.


With the INTO clause you don't need to define tables explcitly.
But I wouldn't say it's a clean way of writing code.

Don't need to is surely an understatement: you are not allowed to, I think?
So other than whether INSERT <select list etcetera> INTO <name> is something that is sensible to have in SQL (I think it is) the question is rather meaningless.


Tom
Post #1496175
Posted Wednesday, September 18, 2013 6:06 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 1:14 PM
Points: 40,615, Visits: 37,081
L' Eomot Inversé (9/18/2013)
Don't need to is surely an understatement: you are not allowed to, I think?


If you mean the SELECT * INTO, unfortunately that's allowed. I've cleaned so many of those out of client code.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1496178
Posted Wednesday, September 18, 2013 6:19 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 1:27 PM
Points: 868, Visits: 7,505
GilaMonster (9/18/2013)
L' Eomot Inversé (9/18/2013)
Don't need to is surely an understatement: you are not allowed to, I think?


If you mean the SELECT * INTO, unfortunately that's allowed. I've cleaned so many of those out of client code.


I can't convince them that SELECT * INTO is bad.


--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
Post #1496180
Posted Wednesday, September 18, 2013 6:20 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 1:27 PM
Points: 868, Visits: 7,505
Jack Corbett (9/18/2013)
Stefan Krzywicki (9/18/2013)
Koen Verbeeck (9/18/2013)
Stefan Krzywicki (9/18/2013)
Am I wrong in saying we shouldn't be using
SELECT * INTO #A1 FROM Table

SELECT * INTO #B1 FROM #A1

in production code? #A1 & #B1 are also never defined explicitly.


With the INTO clause you don't need to define tables explcitly.
But I wouldn't say it's a clean way of writing code.


Yeah, not defining things explicitly bothers me.


I'm just trying to figure out why it isn't just:

Select * INTO #B1 from Table

I'm just assuming that there is some kind of processing on #A1 that you aren't showing.


Yes, there is processing. And then again for several more SELECT * INTOs


--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
Post #1496181
Posted Wednesday, September 18, 2013 6:31 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 1:14 PM
Points: 40,615, Visits: 37,081
Stefan Krzywicki (9/18/2013)
GilaMonster (9/18/2013)
L' Eomot Inversé (9/18/2013)
Don't need to is surely an understatement: you are not allowed to, I think?


If you mean the SELECT * INTO, unfortunately that's allowed. I've cleaned so many of those out of client code.


I can't convince them that SELECT * INTO is bad.


May I suggest a cricket bat?



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1496185
Posted Thursday, September 19, 2013 5:20 AM


Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Yesterday @ 12:04 PM
Points: 328, Visits: 3,624
Stefan Krzywicki (9/18/2013)
GilaMonster (9/18/2013)
L' Eomot Inversé (9/18/2013)
Don't need to is surely an understatement: you are not allowed to, I think?


If you mean the SELECT * INTO, unfortunately that's allowed. I've cleaned so many of those out of client code.


I can't convince them that SELECT * INTO is bad.


Actually, in my experience the SELECT * INTO #A ... type pattern you describe is *extremely* useful. Whenever I've seen it used, it's highly correlated with a codebase so eyebleedingly bad that the perpatrator(s) should be escorted from the premesis as soon as possible.

Is this code, by any chance, also stuffed with over/mis use of temporary tables because the person doesn't seem entirely clear on what they're doing? Just a guess.


I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
Post #1496316
Posted Thursday, September 19, 2013 6:01 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, December 16, 2014 1:57 PM
Points: 1,059, Visits: 1,794
andrew gothard (9/19/2013)
Stefan Krzywicki (9/18/2013)
GilaMonster (9/18/2013)
L' Eomot Inversé (9/18/2013)
Don't need to is surely an understatement: you are not allowed to, I think?


If you mean the SELECT * INTO, unfortunately that's allowed. I've cleaned so many of those out of client code.


I can't convince them that SELECT * INTO is bad.


Actually, in my experience the SELECT * INTO #A ... type pattern you describe is *extremely* useful. Whenever I've seen it used, it's highly correlated with a codebase so eyebleedingly bad that the perpatrator(s) should be escorted from the premesis as soon as possible.

Is this code, by any chance, also stuffed with over/mis use of temporary tables because the person doesn't seem entirely clear on what they're doing? Just a guess.


I've seen it in places with cursor (sorry for the foul language) misuse mostly...
Post #1496343
Posted Thursday, September 19, 2013 6:31 AM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Today @ 6:28 AM
Points: 680, Visits: 6,855
venoym (9/19/2013)
andrew gothard (9/19/2013)
Stefan Krzywicki (9/18/2013)
GilaMonster (9/18/2013)
L' Eomot Inversé (9/18/2013)
Don't need to is surely an understatement: you are not allowed to, I think?


If you mean the SELECT * INTO, unfortunately that's allowed. I've cleaned so many of those out of client code.


I can't convince them that SELECT * INTO is bad.


Actually, in my experience the SELECT * INTO #A ... type pattern you describe is *extremely* useful. Whenever I've seen it used, it's highly correlated with a codebase so eyebleedingly bad that the perpatrator(s) should be escorted from the premesis as soon as possible.

Is this code, by any chance, also stuffed with over/mis use of temporary tables because the person doesn't seem entirely clear on what they're doing? Just a guess.


I've seen it in places with cursor (sorry for the foul language) misuse mostly...




So what happens when you add a column (or several) to #A?
Or change the order of some of the columns?
Does the processing break?
What risk / disruption to the business would this cause?

When you take the time to define, it is much easier to troubleshoot when something breaks.
And much clearer what is being done to everyone that follows.
Dynamic is one thing, but it takes a bit more thought to do it correctly.

This always reminds me of the Excel recorded macro.
When rows and column counts change, most of them break.
Post #1496355
« Prev Topic | Next Topic »

Add to briefcase «««4,1294,1304,1314,1324,133»»»

Permissions Expand / Collapse