other way round... almost looks like someone forgot to commit the transaction - and with those lock hints....ouch

i' advise scripting up your logins and users then drop them all.

create your logins first and then your users within the database.

failing that it's sp_changuserslogin.

my bad... it's only when you create the publication and go to choose the distributor that it checks - but would advise (if possible) to go as high as you...

yes, but your distributor always has to be the highest sql version compared to publisher and subscriber

it wasn't too clear from your description what you wanted

if you want to update each row based on it's own values then

update driver set rateid= case when rateid=40 then 0...

select y.id,y.name1,x.address1,y.newaddressflag,y.current address from ##temp y inner join (select distinct id,address1 from #temp where newaddressflag='Y') x on x.id=y.id

right click on the server and use activity monitor - order it by the head blocker column - you should be able to see a better picture of what is...

something like

select y.id,y.name1,x.address1,x.newaddressflag,y.currentaddress from ##temp y inner join (select distinct id,address1 from ##temp where newadressflag='y') as x  on y.id=x.id

first of all, are these functions deterministic? how many times do you use the view ? do you reference any of these functions in the where clause?

personally i've used persisted...

are you running sql server express? in older versions it would throttle your speed down if you had more than 5 connections open - every extra connection halved its speed...

1st step - change the schedule to 7.30pm - then if it still fails we can rule out the time issue

if it still fails we can look at other options

my understanding is that it is number of processors -1 up to a maximum of 8 for the number of tempdb files

initial size , you are going to have to...

1. a plan will stay in the procedural cache for a varying amount of time - memory pressure, data changes, new indexes etc may all push the plan out of...

the query store is a useful tool, but as soon as your proc cache changes or you reboot your server then you start losing all of the valuable information it...

I might be tempted to do it in 2 stages

select * from dupes inner join (select first4 from dupes group by first4 having count(*) >1) dupes2  on dupes2.first4=dupes.first4

you might have...