Viewing 15 posts - 56,731 through 56,745 (of 59,069 total)
Peter,
Ol' friend, thanks for the feedback. I haven't been "blessed" with 2k5 yet, so I always wonder how these things work out there.
Yes, you're correct. Randy originally said that this...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 19, 2007 at 6:29 am
Randy and Ken,
Yeah, it's pretty much an addiction to me.
Thanks for the feedback... it's part of the addiction ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
March 19, 2007 at 6:16 am
Peter, not sure what your's would do if you added a primary key to the table but it currently take about 15 seconds to do 4,000 rows, 60 seconds to...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2007 at 3:32 pm
As some have suggested, both methods get pretty slow, even in the presence of proper indexing, simply because of the triangular joins involved. As is typical of large triangular joins,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2007 at 3:12 pm
Yep... I have to agree... single table would be the way to go... makes for "common code" which makes life simple and you don't have to use dynamic SQL or...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 18, 2007 at 7:43 am
I think that once you read my "long" post with the sample code, you'll find that 10 reps on a single job will be the way to go... 
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2007 at 8:53 pm
As some have suggested, step 1 would be to ensure the Recovery Mode on TempDB is set to SIMPLE.
Step 2 would be to rewrite your code so it doesn't use...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2007 at 10:31 am
Oki-doki... change of plans... decided to go full-bore on this one (Man! This one was FUN!
). First, if you had SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2007 at 9:07 am
I was doing some checks on your formulas... because of the integer math you are using everywhere, you're coming up with the Statistical Median when you have an even number...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2007 at 7:41 pm
The "Pivot option" you speak of is not available in SQL Server 2000... and this IS an SQL Server 7/2000 forum.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2007 at 4:46 pm
I would solve each of the 4 separately... the ol' "peel one potatoe at a time" usually works the best on these types of things but, of course, that's your...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2007 at 4:45 pm
Richard,
Michael is correct... the most efficient way is to simply make sure that GETDATE() is used in the procs that update the table. As you point out, that does not...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2007 at 4:48 am
No... it only get's updated on INSERT... like any default, it WILL NOT BE APPLIED DURING UPDATES... for example...
USE TEMP
CREATE TABLE ModifyTest(SomeCol INT, ModifiedDate DATETIME)
GO
CREATE...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2007 at 4:29 am
First, I think the use of global (##) temp tables, as you have, will eventually burn you with a "table already exists" error. Recommend you change them to local (#) temp...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2007 at 4:03 am
There are about a thousand posts about this on this forum. Please do a search on "crosstab" and "pivot".
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2007 at 3:47 am
Viewing 15 posts - 56,731 through 56,745 (of 59,069 total)