The SQL 2008 documentation covers it very well.

Is this an indexed view? Also are you just doing a raw select on the view or do you have some sort of qualification on the select?

Do you want quick or do you want minimally disruptive. They are both options...

So is it confirmed that rebuild clustered index WILL ONLY DROP AND CREATE CLUSTERED index. Period, full stop. It only reindexes the index you specifically asked it to...

Thanks

Try

SELECT

Table1.DocumentDate,

Table1.EmployeeNumber,

count(*)

FROM Table1

WHERE User_id='1076'

AND Timeslip LIKE '%99'

Group by Table1.DocumentDate,

Table1.EmployeeNumber

Having count(*) > 1

or even

select a.* from

Table1 a,

(SELECT

Table1.DocumentDate,

Table1.EmployeeNumber,

count(*)

FROM Table1

WHERE User_id='1076'

AND Timeslip LIKE '%99'

Group by Table1.DocumentDate,

Table1.EmployeeNumber

Having count(*) > 1) b

where...

About 98% sure that in 2005 and higher that rebuilding the clustered index does not force a rebuild on all of the other indexes in the table.

Actually I just confirmed...

Is your IIS instance using SQL Server? Is it on the same server?

Yeah that would work, we have code that basically does the same thing.

Any chance you are doing this on a cluster?

I think SharePoint is designed so that it can deal with the crawl being the victim in a deadlock. So in this case it might be annoying but it...

Why do you have to shrink them? Are you running out of space? Is it a charge back thing?

If you are in simple mode, if anything I would...

Well....

If you are in simple mode the log is generally that big because that is how big it needs to be to complete all of the open transactions at that...

Yeah, that's kind of what I figured but it never hurts to ask... 🙂

Yes in the best of all possible worlds this would be addressed via the application.

I am not looking for suggestions on application development.