On thing to consider is that as of SQL 2008 anything over 2 parts in the SELECT statement is considered deprecated. So - put your database+owner names in the...

I'm not sure what you mean by okay. You're the one who determines what "okay" is.

If it returns what you want it to return, then that's something....

All due respect, but - why would you do that to such a nice problem?

I just don't see what the recursize part would do to help....

I'm not sure about a view, since the ORDER BY is critical in this piece.

That being said, you could user something like this

select f1,f2,f2

from

...

Try this

if object_ID('tempdb..#emplist','U')<>0

Drop Table #emplist

if object_ID('tempdb..#empshifts','U')<>0

Drop Table #empshifts

go

declare @g datetime

select @g=getdate()

CREATE table #empList (

[empID] int NOT NULL,

[ShiftType] int NULL,

[StartDate] datetime NOT NULL,

[EndDate] datetime NOT NULL

)

INSERT...

Use the new ROW_NUMBER() feature in 2005.

select *,

Row_number() over (PARTITION BY PersonID)

From

tblPerson

Partition by works...

Not that it's much of a consolation, since the "outer code" is that of a cursor...

I just had to draw the line at second-order loops (loops of loops)..:)

Baby steps.....

skip the d*** loops. Use a numbers table to do this:

INSERT INTO @empShifts ([empID],[ShiftDate],[ShiftType],[StartDate] ,[EndDate])

select @input_empID ,

@current,

...

Grant, myself and a few others have all mentioned that you're missing a JOIN predicate in the "inner join". It's not the optimizer - the query itself is flawed....

Richard - try the Disk usage by table report (right-click on the DB, standard reports). You may find that while the data space went up, the "available space" also...

Nope - referring to the fact that you're stored an XOR on the parity, so you got to pull all of the pieces (even if you updated only one) to...

Actually - if I remember correctly - the wider your raid-5, the bigger the write performance hit you take on random writes, since you now have to do more reads...

Have you tried rebuilding the clustered index on that table? Just curious.

Of course - the plan might be lying, but you haven't posted the query, so we're not going to be able to tell you that..... Just a thought.

Apparently your two joins aren't equivalent, because in one case (the inner join) the "stream aggregate" step estimates the rowcount to be 3.5 Trillion rows (that's 3 commas in there)....