oops...sorry didnt remove constraint

--this one returns a count of all

SELECT count( case when tblUseOfForce.PhysicalForce = 1 then tblUseOfForce.Taser else null end ) AS Taser

, count( case when tblUseOfForce.PhysicalForce = 1...

--this one returns a count of all

SELECT count( case when tblUseOfForce.PhysicalForce = 1 then tblUseOfForce.Taser else null end ) AS Taser

, count( case when tblUseOfForce.PhysicalForce = 1 then tblUseOfForce.PhysicalForce else...

i ran what u had and it looked good unless i'm missing something.

declare @linkedserver varchar(100),

@dbname varchar(100),

@destination varchar(500),

@sqlstr varchar(1000)

set @dbname = 'AdventureWorks'

select @linkedserver = 'QAServer1'

set @destination = @linkedserver+'.'+@dbname+'.'+'sales.'

set @sqlstr = 'select...

declare @oldip varchar(100)

declare @newip varchar(100)

select distinct oldip

, newIp

, 0 processed

into #ips

from tableName

while exists ( select top 1 * from #ips where processed = 0 )

begin

select top 1...

update tableName

set phonenumber = '('+cast( left( rand() * 1000,3) as varchar) + ') '

+ ''+cast( left( rand() * 1000,3) as varchar) + '-'

+ ''+cast( left( rand() * 10000,4)...

i've found that the param sniffing issue is usually specific to u setting a param that has a default vaule that it will typically not have. For example i had...

rather than delete u could recreate a version of the table w just the records u want then do the old switcheroo. Rename it to _archive then rename the new...

not fully understanding

are u saying 10.1.@ would come before 17?

I don' treally care weather it comes back different between using nolock or not, i just enjoy finding inconisencies in the system and finding out why these inconsistencies exist for...

So thats that. Is there a way for me to close this or do i just leave it?

i just used the term mostly static so that u guys would answer saying perhaps records are being updated at a high rate causing the issue.

I suppose another important question is if the nolock overall will provide a performance boost in certain scenerios due to the less reads than w/o.

Thats the question. The one w/o nolock reads more pages. Why? Or better yet why would the one w/ (nolock) read from just one page?

That explains why both versions return the same result sets respectively just not the same between the two. 😉

RESOLUTION!!!!!!!!!!!

On SQL 2000, the Microsoft Search must have System admin access in SQL Server. Because this is SQL 2000, the only way to add this security is to give the...