It's a bug... turn off task pad by selecting a different kind of view... then, turn it back on. Problem should fix itself. If it doesn't you may...

John, you happen to have come to the right place at the right time...

There are several methods to do this, but for shear performance, nothing beats the method I'm getting...

Chris Schanno (3/6/2008)

---

Jeff,

Yes, I would consider using a cursor over the set based approach depending on the circumstances such as the size of the dataset and use for which I...

Sorry, previous knowledge... he's asked for it before on a different thread.

Jacob Luebbers (3/6/2008)

---

Thanks for the insight Jeff. I've done some re-checking of my old assumptions and it turns out the TempDB locking contention from SELECT... INTO... was only a major...

The join needs to be part of the covering index or you will only get a scan.

The tuning wizard is recommending a full blown "Covering Index" and it's a good thing to have for a heavy duty set of SELECT's like this. It will, however...

The only way either of those would fail is if the data is different that what you said. Please post some sample data and a table to load it...

a-brbeck (3/6/2008)

---

I submit that the absolute best optimization of the statement is: “SELECT column1, column2, column3 FROM table WHERE MONTH(datefield)=1”. In other words, with the exception of the use of...

Oooohhh... I just ran into that paging problem... really bad case of parameter sniffing and the traditional methods don't fix it... only full blown dynamic SQL fixes it... lemm see...

p.s. You friend DOES know what Books Online is, doesn't (s)he??? I figure if you have to ask questions on this forum for him/her, they just might not...

A week of preparation on this is not enough... but I'd say your best bet is to curl up with Books Online for the next week...

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/e9099cce-7f81-4808-8523-587bbcdc1720.htm

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/c2eb5f77-2dc1-49b4-bd19-2cdac4c6cae1.htm

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/31529dfe-68e7-49f7-b3c2-39fcecf33a95.htm

... an exam-cram of this...

Just another test... please ignore.

Just a test... please ignore...

Perhaps a permissions change on SQL Server or someone removed a "share" from the target drive... or, maybe the file isn't there anymore... or the machine the file is on...