Viewing 15 posts - 33,601 through 33,615 (of 59,099 total)
At this point, my recommendation would be to build a Calendar or Date table. If you have problems finding a good one on Google or Yahoo (or whatever your...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 6:31 pm
jmaloney-1117255 (6/17/2011)
Steve Hoyer (6/17/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 6:22 pm
glen.wass (6/17/2011)
HI, try looking up variable temp tables, as i understand it these work from memory...
It's a myth... Table Variables aren't "memory only" (which is what I believe you were...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 4:48 pm
Jayanth_Kurup (6/17/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 4:44 pm
opc.three (6/17/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 4:38 pm
allmhuran (6/17/2011)
My mind first jumped to indexing but I don't think it makes sense. Why would a reboot fix it?
Because a reboot clears proc cache. It's like telling...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 6:13 am
Carlton Leach (6/17/2011)
Also, depends on the code that's being written by your developers.
Exactly. 🙂 "Accidental Cross-Joins" (think many-to-many joins frequently overcome by the use of DISTINCT or GROUP BY)...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 5:51 am
Brandie Tarvin (6/16/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 5:47 am
Jayanth_Kurup (6/17/2011)
try using ctes
Oh, be careful, now. That can actually make the problem worse especially if the data in the result set of the CTE is needed more than...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 5:33 am
yasubmj (6/17/2011)
Here is the code in the sp which takes a lot of time, around 17 secs, the reads are only 1303,
SELECT
col1, col2, col3....,
(CASE @LocDBSortOrder
WHEN 'DESC' THEN
CASE @LocstrSortExpression...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 5:22 am
Brandie Tarvin (6/16/2011)
If you don't have an Identity, add it to the table.
I prefer a method which exploits the IDENTITY column, as well, but it's just not possible to add...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 5:10 am
bitbucket-25253 (6/16/2011)
For a matter of record the above code was copied from a posting by Jeff Moden on a SSC forum, and not my work, but one I use frequently.
You,...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 5:08 am
Sriram.RM (6/16/2011)
SET ROWCOUNT 1
DELETE YOURTABLE
FROM YOURTABLE A WHERE (SELECT COUNT(*) FROM YOURTABLE B WHERE A.COLNAME=B.COLNAME) >1
WHILE @@ROWCOUNT >0
DELETE YOURTABLE
FROM YOURTABLE A WHERE (SELECT COUNT(*) FROM YOURTABLE...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 5:03 am
vaibhavraut88 (6/16/2011)
Great Job dude ur script works. but can u explain me that code.
Ummm.... which script? The one with the WHILE Loop or the other one?
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 5:01 am
opc.three (6/16/2011)
:Wow: I just set myself up big time huh?
Nah... considering the number of hacker attacks designed specifically to exploit OLE DB Automation, I can see your point especially in...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 17, 2011 at 4:50 am
Viewing 15 posts - 33,601 through 33,615 (of 59,099 total)