Viewing 15 posts - 34,741 through 34,755 (of 59,099 total)
foscsamuels (3/8/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 9:51 pm
Craig Farrell (3/7/2011)
*facepalm* You're right, of course... what I get for untested code.
Not your fault for not testing. It's what happens when the OP doesn't post readily consumable test...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 9:46 pm
As a bit of a sidebar, although USING has been implemented in many database engines, I hope it never takes off in SQL Server... I just don't like "natural" joins...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 9:42 pm
S-322532 (3/8/2011)
Thanks for the reply. Forget to mention one thing; the tenure of a person ends when the next person joins the office.
Check the data below:
snoENameDOJ
1axx2008-03-08...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 9:16 pm
I agree. Jim explained it quite well. I'll also add that if you expect a high volume of hits against something that is likely to continue to exist...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 9:13 pm
Deee -Daah! (3/8/2011)
Need some help once again please. I'm not sure I know how to group by on the sample data below to get the desired result. As always,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 9:05 pm
wiklander79 (3/8/2011)
My delete trigger only fires at one row when there are multible...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 8:10 pm
Since the numerator and denominator are likely of the INT datatype, you can simply change this...
((a.numerator/b.denominator) * 100)
... to this...
a.numerator*100.0/b.denominator
... and you'll get your decimal places. ๐
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 8:08 pm
Michael Viglas (3/8/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 8:04 pm
dba.varun.in (3/4/2011)
I solved the situation spend 1 whole day,Hope this may help u guys,
select A.ID,A.Invoice_Amount,a.Payment_Amount,A.CID,ISNULL(A.Payment_Amount -
(select SUM(B.Invoice_Amount)+A.Invoice_Amount
from TestDetails B
where B.ID < A.ID
and b.cid = A.cid
),A.Payment_Amount -...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 7:56 pm
Rob Reid-246754 (3/3/2011)
and the performance has increased dramatically.The previous UPDATE that was taking upwards of 5+ minutes is now returning in <7 seconds for 11 runners.
I'm glad you found the...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 6:54 pm
Sean Lange (3/7/2011)
The sql...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 6:29 pm
jcrawf02 (3/7/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 6:25 pm
vishal.gamji (3/8/2011)
SSIS will be much faster in this case. Use lookup transform to find the referenced table columns you need.
I'd love to see the test that proves that. ๐
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 2:34 pm
DucatiRider (3/8/2011)
I needed to add a READ | UNCOMMITTED statement, (we don't want to do NOLOCK) to the code because there were performance issues.
Just a note of caution... Even though...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 8, 2011 at 2:29 pm
Viewing 15 posts - 34,741 through 34,755 (of 59,099 total)