Viewing 15 posts - 48,511 through 48,525 (of 59,102 total)
Richard Fryar (9/1/2008)
There is a sneaky way of doing this described here:
Heh... I love "sneaky". That's awesome! Thanks for the tip! 🙂
EDIT - BEWARE !!!! THE LINK ABOVE...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 5:31 pm
Pulkit Lall (8/31/2008)
So, the answer is 5 resultsets with 5...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 3:05 pm
GilaMonster (9/1/2008)
If today's programmers can count on faster disk drives, essentially memory speed, are we going to see more and more bad SQL in tomorrow's databases?
Of course, because there are...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 3:03 pm
Ah... got it... thanks for the feedback.
Still, if the table were properly normalized, this would be a piece of cake. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 3:01 pm
Good article!
You did forget to mention one workaround for the UDT's that would allow it to work across all databases including TempDB... Define the UDT in the Master...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 2:56 pm
gan (8/31/2008)
I get 1469283328 for that. Sorry I do not quite understand what you are trying to explain. Can elaborate more? 😀
Yes... but please look at the actual execution plan...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 2:29 pm
balbirsinghsodhi (9/1/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 2:18 pm
pujashah10985 (9/1/2008)
I'm getting this warning when I run the report:
If you create a stored procedure to return a result set using the methods in the following article (mentioned previously on...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 11:26 am
gardenlady (8/29/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 11:21 am
Dougo (8/31/2008)
I actually used alter index, so rebuild. I also dropped and recreated the index.
Then, you must be looking at "extent fragmentation"... just hide that from your eyes... the big...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 11:03 am
Heh...
I appreciate the advertised "simplicity" of your product, but don't try to justify it by posting a bunch of bloated links with bad information in them. 😉
Both the UPDATE...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 10:58 am
Steve Jones - Editor (8/31/2008)
What about a fast triangular join? Maybe it will flatten out to a linear algorithm :hehe:
Shoot! It's flat now... all you need is some Log/Log...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 31, 2008 at 6:24 pm
If today's programmers can count on faster disk drives, essentially memory speed, are we going to see more and more bad SQL in tomorrow's databases?
Heh... The answer, just like horizontal...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 31, 2008 at 10:08 am
Which version of SQL Server 2005 are you trying to install?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 31, 2008 at 9:53 am
rbarryyoung (8/31/2008)
I think that you should also check for a Create Proc DDL trigger on this database.
I think you're on to something there, Barry...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 31, 2008 at 9:44 am
Viewing 15 posts - 48,511 through 48,525 (of 59,102 total)