Sorry, I'm still stuck on SQL 2000 with this...

e.g. for test purposes

create table mytable (id int not null identity(1,1) primary key,

col2 varchar(150) not null ,

col3 datetime not null default getdate() )

go

/* Fill table with 15000 rows */

insert...

I have the same issue, and posted a question a while ago:-

http://www.sqlservercentral.com/Forums/Topic534396-9-1.aspx

There is a link to some MS articles about the problem, but the solutions are painful!

Oops, sorry - helps if I read the whole post.:Whistling:

xp_fileexists won't work with networked...

Does the service account that SQL Server runs under have permissions to the networked drive?

If you are running SQL Server under the local system account, it will have no access...

Using exactly the same hardware, data, workload etc, I saw an overall improvement of about 20% after upgrading to SQL 2005 (leaving the databases in 80 compatibility).

And... SQL Server 2000...

What happens seems to depend on the SQL Client/Options in use, rather than which version of SQL is at the back end.

The script executes 10 times if I run it...

Sounds as though someone has manually created some statistics on the column using CREATE STATISTICS.

Just drop the statistics using

DROP STATISTICS MEMBER_DETAIL.MEMBER_TYPE

before altering the column

Do you have the AutoShrink option switched on for the database?

I have frequently seen that sort of behaviour.

Setting the "Collation Compatible" option to true for the linked server has helped occasionally. This is what BOL has to say about to...

Just to add to Jack's (very good) explanation:-

If SSN, LastName, FirstName, MiddleName, DateOfBirth are the primary key, what happens if LastName changes through marriage or mistyping in the first place......

It doesn't make any difference in which order you write the WHERE clause.

SQL Server will look at the WHERE clause as a whole, and work out the best way...

Replication will complain if it tries to replicate a delete to server 2, and your users have already deleted this data, or an insert that already exists etc.

You will need...

If the job is scheduled to run automatically, it will start with the correct step.

It's only if you invoke the job manually, that it asks which step to start...

The sysntax is right, but now it either can't find the server, or the server won't allow the remote connection. Are you sure there isn't a typo in the instance...