Viewing 15 posts - 48,496 through 48,510 (of 59,095 total)
bumey309 (9/1/2008)
Why is it not recommended to have the database and transaction logs on the same drive? What will be the cause if ever?
The biggest reason is simply performance. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 6:39 pm
Jeffrey Williams (9/1/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 6:35 pm
Christopher Stobbs (9/1/2008)
Type is there for backward compatibility
I wonder why some of the folks from Redmond saw fit to use it to define some of the information schema views if...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 6:28 pm
Heh... I'm thinking this is strong justification for tele-commuting. 😛 Let's all become agoraphobic and avoid the epidemic, conspiracys, and a modicum of common sense. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 6:25 pm
Do like Excel does... do the calculations using FLOAT (Barry implied it with 100.0) and then round the answer to the correct number of decimal points for display. If...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 6:18 pm
OpenRowset cannot take variables as part of it's syntax. You'll need to do the whole OpenRowset thing as dynamic SQL.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 5:40 pm
As previously suggested, have you looked into "parameter sniffing"? Google it.
Also, are there any settings differences between the two servers like "auto statistics", etc. Last but not least,...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 5:38 pm
It could simply be a case of "parameter sniffing"... Google it.
Also, are "auto statisics" enabled or not?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 1, 2008 at 5:34 pm
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
Viewing 15 posts - 48,496 through 48,510 (of 59,095 total)