Viewing 15 posts - 30,706 through 30,720 (of 59,101 total)
the sqlist (3/15/2012)
Jeff Moden (3/15/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2012 at 10:15 am
Kingston Dhasian (3/17/2012)
Jeff Moden (3/16/2012)
er.sivaganesh (3/16/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 17, 2012 at 8:47 am
You bet. If you get the chance, let us know how it pans out for you.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 11:48 pm
er.sivaganesh (3/16/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 11:42 pm
CELKO (3/16/2012)
You have no idea what first normal form means and that...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 11:32 pm
manjunath.dacca (3/16/2012)
Written a query which returns as shown belowBagalkotBadamiR.B.Patil
BagalkotBadamiSunil Kambar
The result expected is
BagalkotBadamiR.B.Patil,Sunil Kambar
how to do this?
You'll find your answer at the following excellent link written by wayne Sheffield.
http://www.sqlservercentral.com/articles/comma+separated+list/71700/
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 11:27 pm
Ah, understood. I was going by what you had posted for code.
Shifting gears a bit, I'm concerned about your "busy" Temp DB. This is frequently caused by things...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 9:41 am
capn.hector (3/16/2012)
Depending on the application would using the created on date for the first modified date be better than some future date?
so in the above query it would be rewritten
select...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 9:27 am
These types of problems with VM are typically are not code related. A lot of folks setup VM to move resources to and from SQLServer servers and, when such...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 9:22 am
dwain.c (3/15/2012)
;WITH PLYTD AS (
SELECT Account, Organization, Period, [Year]
,(SELECT SUM(Amount) FROM @acct a2
WHERE a1.Account = a2.Account and a1.Organization = a2.Organization and a1.[Year] = a2.[Year] and
a2.Period <= a1.Period
) As...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 7:45 am
As written, it also creates a performance problem because it will never use an INDEX SEEK. This type of predicate is frequently referred to as a "non-SARGable" predicate. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 7:23 am
Apologies... I have no clue what the problem could be. We have a VM environment at work and it screams.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 7:14 am
p.s.
The word "dude" isn't always a complimentary one. You might want to avoid it's use.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 6:56 am
manub22 (3/15/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 6:55 am
Oh... be careful, now. That only works if each top level item only has a straight trunk instead of a tree. Run the code with the following data...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 16, 2012 at 6:35 am
Viewing 15 posts - 30,706 through 30,720 (of 59,101 total)