Are the posted questions getting worse?

Question

Are the posted questions getting worse?

Viewing 15 posts - 5,431 through 5,445 (of 66,712 total)

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

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 1

Paul White (6/6/2009)
The requirement to alias a table variable for UPDATE is not spectacularly well documented in BOL. A quick skim over the entry for the UPDATE statement revealed nothing to me - I may have missed it, but I don't think so. It is logical once you think about it, but I don't think it is obvious.

It is logical. But, it's also an undocumented feature (it's not to be found in BOL or any Microsoft document I've ever seen). With that in mind, lots of folks say to never use undocumented features because they could change anytime without notice.

I normally don't worry about using undocumented features because they also change documented features without notice. To wit, look what they did with sp_MakeWebTask on SQL Server 2000 sp4. That little change in security broke a lot of code.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 2

GSquared (6/5/2009)
Just remember, your porkchop delivery method needs to be scalable for that kind of thing. After all, you of all people wouldn't want to accidentally end up with a porkchop-by-agonizing-porkchop solution!

Heh... throwing them one at a time with a pause to see the effect is more than half the fun. 😛

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Paul White SSC Guru Points: 150467 More actions · Answer 3

GilaMonster (6/6/2009)
...stuff I agree with entirely...

Nice post Gail. I think BOL could definitely benefit from some clarification so anything you can help along there would be all good.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Paul White SSC Guru Points: 150467 More actions · Answer 4

Jeff Moden (6/6/2009)
It is logical. But, it's also an undocumented feature (it's not to be found in BOL or any Microsoft document I've ever seen). With that in mind, lots of folks say to never use undocumented features because they could change anytime without notice.

I deliberately said 'not well documented' because I had seen it in BOL - see Gail's post for the link. It's just in totally the wrong place, or needs an xref or something. It certainly caught me out when it was first introduced.

Jeff Moden (6/6/2009)
I normally don't worry about using undocumented features because they also change documented features without notice. To wit, look what they did with sp_MakeWebTask on SQL Server 2000 sp4. That little change in security broke a lot of code.

Absolutely. I love it when someone brings up the 'if you use undocumented features your wife will leave you' type of argument, for exactly those reasons. It seems to me that documented behaviour is perhaps even more likely to be 'deprecated' and/or broken in subsequent releases. I think the planet would stop spinning if sp_foreachdb and the like were ever removed!

BTW, reading the 2K8 BOL entry on table variables - it seems that table variables no longer force a fully serial plan - hoorah! Reading is ok, just don't modify a table variable. That is a very cool change in behaviour.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 5

GilaMonster (6/6/2009)
WayneS (6/6/2009)
You know, it's always those complex T-SQL concepts that trip up so many people.
Good going Gail!
I know. Those darned updates are just so hard to understand. :hehe:
Correct link - http://www.sqlservercentral.com/Forums/FindPost730218.aspx

I just had to look at that one. It's always amazing to me that someone asks for help, reads the code, misunderstands it (of course, they're the one asking the question), doesn't even try the code, and the crabs about it. There's no language barrier problem there... lots of other barriers but not a language barrier.

Whats really funny is that they're always surprised to have someone say "you didn't try the code" and for them to be correct. I guess they think that no one actually tests code even though you pointed out the bad code in the test harness on that one.

As Paul pointed out about the "apology", I think that person finally got the whole idea of what a forum is about. I'm just always amazed that they don't think that way when they start out because it just seems so bloody logical to actually try someone's code before you crab about it.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Alvin Ramard SSC-Forever Points: 41190 More actions · Answer 6

Paul White (6/6/2009)

..... 'if you use undocumented features your wife will leave you' ......

FYI, wives come with undocumented features too.

😀

Alvin Ramard
Memphis PASS Chapter[/url]

All my SSC forum answers come with a money back guarantee. If you didn't like the answer then I'll gladly refund what you paid for it.

For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 7

Paul White (6/6/2009)
I deliberately said 'not well documented' because I had seen it in BOL - see Gail's post for the link. It's just in totally the wrong place, or needs an xref or something. It certainly caught me out when it was first introduced.

Heh... understood. I was just crabbin' about the lack of documentation on it. Not crabbin' at you. 🙂

Gail's BOL link doesn't work for me when I paste it into the help URL field. I'm still using 2k5 if that matters.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Paul White SSC Guru Points: 150467 More actions · Answer 8

Alvin Ramard (6/6/2009)

Paul White (6/6/2009)
..... 'if you use undocumented features your wife will leave you' ......
FYI, wives come with undocumented features too.

ROFL!!!

I live in hope of a QFE...

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Paul White SSC Guru Points: 150467 More actions · Answer 9

Jeff Moden (6/6/2009)
Paul White (6/6/2009)
I deliberately said 'not well documented' because I had seen it in BOL - see Gail's post for the link. It's just in totally the wrong place, or needs an xref or something. It certainly caught me out when it was first introduced.
Heh... understood. I was just crabbin' about the lack of documentation on it. Not crabbin' at you. 🙂

I didn't think you were! Gosh but this medium is limited sometimes - could everyone please assume that I'm not being snarky by default please? I will add BEGIN SNARK...COMMIT/ROLLBACK SNARK to future posts where required...:-D 😎 😀

Jeff Moden (6/6/2009)
Gail's BOL link doesn't work for me when I paste it into the help URL field. I'm still using 2k5 if that matters.

Linky: http://msdn.microsoft.com/en-us/library/ms175010(SQL.90).aspx

BTW on behalf of Cancerians everywhere, what's all this with the crabbin'??? 🙂

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

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

Paul White (6/6/2009)
Absolutely. I love it when someone brings up the 'if you use undocumented features your wife will leave you' type of argument, for exactly those reasons. It seems to me that documented behaviour is perhaps even more likely to be 'deprecated' and/or broken in subsequent releases. I think the planet would stop spinning if sp_foreachdb and the like were ever removed!

From what I understand, the current rule is that documented features have to go through a 1 or 2 stage deprecation cycle (sysobjects, deprecated in 2k5, final deprecation in 2k8. Backup log... truncate only deprecated in 2k5 and gone in 2k8) before they can be removed from the product, whereas undocumented features can be modified or changed at any time with no documentation whatsoever.

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

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

Jeff Moden (6/6/2009)
Gail's BOL link doesn't work for me when I paste it into the help URL field. I'm still using 2k5 if that matters.

It does matter. That link's from the 2k8 BoL. Use the index and look for "Table variables (SQL Server)". Should get you to the right place, though I won't promise it says the same thing.

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

Paul White SSC Guru Points: 150467 More actions · Answer 12

GilaMonster (6/6/2009)
Jeff Moden (6/6/2009)
Gail's BOL link doesn't work for me when I paste it into the help URL field. I'm still using 2k5 if that matters.
That link's from the 2k8 BoL. Use the index and look for "Table variables (SQL Server)". Should get you to the right place, though I won't promise it says the same thing.

It does say the same thing it turns out. I checked in my 2K5 BOL - the link I posted is the equivalent on MSDN. Promise!

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Paul White SSC Guru Points: 150467 More actions · Answer 13

GilaMonster (6/6/2009)
Paul White (6/6/2009)
Absolutely. I love it when someone brings up the 'if you use undocumented features your wife will leave you' type of argument, for exactly those reasons. It seems to me that documented behaviour is perhaps even more likely to be 'deprecated' and/or broken in subsequent releases. I think the planet would stop spinning if sp_foreachdb and the like were ever removed!
From what I understand, the current rule is that documented features have to go through a 1 or 2 stage deprecation cycle (sysobjects, deprecated in 2k5, final deprecation in 2k8. Backup log... truncate only deprecated in 2k5 and gone in 2k8) before they can be removed from the product, whereas undocumented features can be modified or changed at any time with no documentation whatsoever.

Understood. Though there may be practical considerations (probably pork related) which mean that removing/changing certain widely-used undocumented features is unlikely in the extreme. No guarantees of course, so the point is taken.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

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

Paul White (6/6/2009)
Understood. Though there may be practical considerations (probably pork related) which mean that removing/changing certain widely-used undocumented features is unlikely in the extreme. No guarantees of course, so the point is taken.

I dunno. It's happened before. Take the examples of pwdencrypt and pwdcompare. They're undocumented password hashing routines. I believe that the SQL authentication passwords use them (or at least used to on SQL 2000).

They changed between (I think) SQL 7 and SQL 2000. Same syntax, same parameters, completely different result. Really ruined the day of people who used them to hash their own passwords.

Dev team won't go out of their way to change undocumented features just to spite people, but if they need to do so....

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

LutzM SSC Guru Points: 107049 More actions · Answer 15

GilaMonster (6/6/2009)
From what I understand, the current rule is that documented features have to go through a 1 or 2 stage deprecation cycle (sysobjects, deprecated in 2k5, final deprecation in 2k8. Backup log... truncate only deprecated in 2k5 and gone in 2k8) before they can be removed from the product, whereas undocumented features can be modified or changed at any time with no documentation whatsoever.

I think it has to be that way. Otherwise the undocumented feature would become a documented feature by the official announcement of modification/elimination. Wouldn't it? 😉

Lutz
A pessimist is an optimist with experience.

How to get fast answers to your question[/url]
How to post performance related questions[/url]
Links for Tally Table [/url] , Cross Tabs [/url] and Dynamic Cross Tabs [/url], Delimited Split Function[/url]