Are the posted questions getting worse?

Question

Are the posted questions getting worse?

Viewing 15 posts - 41,296 through 41,310 (of 66,712 total)

You must be logged in to reply to this topic. Login to reply

Steve Jones - SSC Editor SSC Guru Points: 736255 More actions · Answer 1

dwain.c (9/16/2013)
Space is something I believe I could easily arrange.
I hear there is one coming up in Manila within a couple of months. I'm anxious to hear when the one in Singapore is scheduled.

We'll likely plan 2014 in Nov/Dec and decide then. If not 2014, then likely 2015. We opened a Singapore office last year, so it's a matter of time.

Greg Edwards-268690 SSC-Insane Points: 20680 More actions · Answer 2

Steve Jones - SSC Editor (9/16/2013)
Greg Edwards-268690 (9/16/2013)
Hope those in Colorado are doing OK.
Floods are so devastating.
Especially when in areas you'd never expect them, and not related to spring run off.
My prayers are with you.
We're fine. Driveway washed low in a few spots, so I have work to do, but otherwise OK. The NoCol group might be struggling. Some evacs up that way, and some washed out roads.

Glad to hear you seem to have dodged the worst.

Heard some parts of Mexico just got 51" of rain.

So hard to fathom when we just had 2 months with no rain.

Seems like we see more extremes all the time.

Ed Wagner SSC Guru Points: 287026 More actions · Answer 3

Greg Edwards-268690 (9/17/2013)
Steve Jones - SSC Editor (9/16/2013)
Greg Edwards-268690 (9/16/2013)
Hope those in Colorado are doing OK.
Floods are so devastating.
Especially when in areas you'd never expect them, and not related to spring run off.
My prayers are with you.
We're fine. Driveway washed low in a few spots, so I have work to do, but otherwise OK. The NoCol group might be struggling. Some evacs up that way, and some washed out roads.
Glad to hear you seem to have dodged the worst.
Heard some parts of Mexico just got 51" of rain.
So hard to fathom when we just had 2 months with no rain.
Seems like we see more extremes all the time.

The western US was burning not too long ago, now it's flooded.

I'm in Michigan and my back yard floods whenever it rains too much too fast because we have a small part of a river flowing through our back yard. Even seeing a couple feet of water accumulate, it's hard to wrap your head around an area getting more than 4 feet of rain. Hurricanes really dump a lot of water quickly. This US hurricane season has been pretty calm so far, but they're not out of the woods yet.

Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions

Sioban Krzywicki One Orange Chip Points: 27770 More actions · Answer 4

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.

--------------------------------------
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

Koen Verbeeck SSC Guru Points: 259105 More actions · Answer 5

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.

Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP

Sioban Krzywicki One Orange Chip Points: 27770 More actions · Answer 6

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

Jack Corbett SSC Guru Points: 184394 More actions · Answer 7

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
Consultant - Straight Path Solutions
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

TomThomson SSC Guru Points: 104773 More actions · Answer 8

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

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 9

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, MVP, M.Sc (Comp Sci)
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

Sioban Krzywicki One Orange Chip Points: 27770 More actions · Answer 10

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

Sioban Krzywicki One Orange Chip Points: 27770 More actions · Answer 11

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

Gail Shaw SSC Guru Points: 1004504 More actions · Answer 12

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, MVP, M.Sc (Comp Sci)
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

andrew gothard SSChampion Points: 12314 More actions · Answer 13

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.

venoym SSCarpal Tunnel Points: 4161 More actions · Answer 14

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...

Greg Edwards-268690 SSC-Insane Points: 20680 More actions · Answer 15

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.