Viewing 15 posts - 49,261 through 49,275 (of 59,099 total)
rbarryyoung (7/11/2008)
this was never possible with the old syntax
That's not true...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 4:52 pm
Heh... good idea... just remember that TRUNCATE won't work in the presence of Foreign Keys... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 4:46 pm
rbarryyoung (7/11/2008)
What are you hoping to get from us?
What Barry means is that you've given us nothing but symptoms. The problem is going to be what appears in the...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 4:43 pm
What you've requested is not a Pivot... it's a "simple" aggregation. Since you've not identified the datatypes involved, I have to make certain assumptions. Please see the link...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 4:38 pm
Heh... I agree, Michael... there's always that. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 3:36 pm
GilaMonster (7/11/2008)
Jeff Moden (7/11/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 3:24 pm
Heh... they already have one! It's called the DATETIME datatype! What they really need is just a simpler way of formatting and they need to allow for the...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 11:05 am
If you're talking about RBAR update/select pairs, that's just a bad programming practice... between the proprietary UPDATE SET @variable = columnname = expression and the OUTPUT clause available in 2005,...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 10:34 am
That's all well and good... I guess people who are unaware could use the help of the Date and Time datatypes. What I'm waiting for is the people who...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 10:30 am
Of course your CLR function is going to beat the T-SQL function... you used RBAR on steriods... you need to test against a correctly written T-SQL function for this to...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 9:43 am
David Griffiths (7/11/2008)
BTW this happens even though the SELECT is the only statement in transaction.
Why on Earth would you put a single SELECT in an explicit transaction???
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 9:36 am
GSquared (7/11/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 9:32 am
GilaMonster (7/11/2008)
Movie schedules. Movie X shows every day this week at 17:00, 20:30 and 23:00
A store list with their...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 9:31 am
There is a method for this in Books Online called "expanding hierarchies"... it has about the same amout of RBAR as a recursive subquery (recursive subqueries are not set based...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 9:24 am
First, let me suggest a minor correction to your code... First, try this... (your original code with a twist on the data)...
[font="Courier New"]DECLARE @OutString NVARCHAR(MAX)
SELECT @OutString = ISNULL(@OutString, '') +...
--Jeff Moden
Change is inevitable... Change for the better is not.
July 11, 2008 at 8:46 am
Viewing 15 posts - 49,261 through 49,275 (of 59,099 total)