Viewing 15 posts - 41,416 through 41,430 (of 59,067 total)
GSquared (10/20/2009)
Reboot when you have to, never otherwise.
I'll second that.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 10:32 pm
Option "A" is known as a "Slowly Changing Dimension Type 2" and, if I recall correctly, Option "B" is "Type 1". I prefer option "A" as I don't hav...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 10:25 pm
I'm not so sure that's true, Steve. Just like with Log Files on full recovery DB's, a time honored server performance "trick" is to move TempDB to it's own...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 10:14 pm
The answer is simple on this one... don't use a permanent table as a staging table... use a Temp Table.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 10:06 pm
Elliott W (10/20/2009)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 10:03 pm
Bob has shown the way with the best performance in 2k5. Lemme show you what you did wrong with yours....
CREATE FUNCTION dbo.fnConcatTest (@PID INT)RETURNS VARCHAR(8000)
AS
BEGIN
DECLARE @Return VARCHAR(8000)
SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 9:49 pm
Heh... like I said...
I know that the use of cursors and loops for flow control is an acceptable use...
... and I agree with all the reasons Bob stated for this...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 9:36 pm
I know that the use of cursors and loops for flow control is an acceptable use but... I just can't bring myself to write one if there is another way...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 9:12 pm
Ummmm.... why build the reporting view at all? Build the table so it looks like the view, index it correctly, and have synonym pointing at the table in...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 6:05 pm
Heh... gettin' old... Seth beat me. Same idea though...
SELECT DATEADD(ss,1,DATEADD(mm,DATEDIFF(mm,-16,GETDATE())-1,-16))
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:55 pm
You shouldn't have to partition anything for a 7k row table because it won't help when returning all rows and columns.
Something is dreadfully wrong if it takes that long to...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:37 pm
A "search" on this site is still one of the best ways to find what you need...
When you run across one of the many articles or scripts on this subject,...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:32 pm
That will certainly work and if you don't have many rows, you probably won't notice, but REVERSE is comparatively very expensive... it would be computationally cheaper if you just used...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:51 am
No problem... just remember that it leaves a trailing comma and does the whole table unless you add a criteria.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:44 am
matt6749 (10/19/2009)
Ok thanks Jeff - I am going to try, and try hard, to implement multiple CTEs like you suggest.. (gulp, wish me luck!) - Matt
You'll do fine... just...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 20, 2009 at 5:40 am
Viewing 15 posts - 41,416 through 41,430 (of 59,067 total)