Table Variable :Doesn't care

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Bhuvnesh » Table Variable :Doesn't care

33 posts, Page 3 of 4

«««1 2 3 4 »»

Table Variable :Doesn't care

Rate Topic

Display Mode

Topic Options

Author

Message

JF1081

Posted Wednesday, July 07, 2010 9:06 AM

SSC-Addicted

Group: General Forum Members
Last Login: Tuesday, December 07, 2010 8:13 AM
Points: 436, Visits: 322

tommyh (7/6/2010)

UMG Developer (7/6/2010)

Nice question, thanks!

I'm a little surprised that so many people have gotten it correct so far, but that may be because of the copy, paste, F5 syndrome. Wink

Or copy, paste, alt+x syndrome (F5 is to far away on the keyboard... and actually clicking execute is WAY out of the question).

Good question though.

I have been wondering what the keyboard shortcut is for execute is. I learned 2 things today.
By the way, this is not that hard to figure out without a copy and paste. I figured that 1,2 for both queries was too obvious; then I realized that one table is a variable so it probably would not be affected by the rollback. I guessed right.
And I am assuming that rolling back a transaction does not change any type of variable to the pre-transaction value?

Post #948610

Jan Sorenson

Posted Wednesday, July 07, 2010 9:22 AM

SSC Veteran

Group: General Forum Members
Last Login: Wednesday, December 12, 2012 11:38 AM
Points: 265, Visits: 116

I like these kind of QOD because they point out the subtle differences in very similar things. After reviewing the post, I have been schooled and am better for it. Regarding the F5 cheating issue, I guess it's a matter of perspective on what game you are playing. For me, I guess I am not playing the traditional game but have engaged in another way of learning, I am just monitoring activity, and learning a lot along the way. Hehe

Post #948621

Rose Bud

Posted Wednesday, July 07, 2010 9:35 AM

Ten Centuries

Group: General Forum Members
Last Login: Thursday, May 16, 2013 9:42 AM
Points: 1,072, Visits: 1,026

Good QotD: Brief, straightforward illustration of something that may be well-known but was new to me.

I must be missing something. In Hrvoje's example, I understand why there are no rows in #t but I don't understand why the 'A' row isn't in @t. Is it because the output into #t fails?

Post #948630

Hugo Kornelis

Posted Wednesday, July 07, 2010 9:58 AM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 2:32 PM
Points: 5,293, Visits: 7,229

wware (7/7/2010)

I must be missing something. In Hrvoje's example, I understand why there are no rows in #t but I don't understand why the 'A' row isn't in @t. Is it because the output into #t fails?

That is because the statement fails. If a statement fails, it has no effect. Not on tables, nor on variables - and hence, not on table variables eiter.
"SELECT @StringVar = 'a', @IntVar = 'a'" would leave both variables unaffected as well.

Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

Post #948664

KevinC.

Posted Wednesday, July 07, 2010 11:53 AM

Right there with Babe

Group: General Forum Members
Last Login: Tuesday, December 07, 2010 12:55 AM
Points: 771, Visits: 504

Excellent question. I learned something new from all the other posts, too. Smile

Post #948741

webrunner

Posted Wednesday, July 07, 2010 12:55 PM

SSCrazy

Group: General Forum Members
Last Login: Tuesday, June 11, 2013 2:08 PM
Points: 2,121, Visits: 2,226

Good question. Got it wrong, and now I know why.

Thanks,
webrunner

-------------------
"The chemistry must be respected." - Walter White

"A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Post #948793