Lutz - I am going to rewrite it set-based, sure.

As I see it, cursors are really meant for interaction between SQL Server

and applications which just cannot understand set-based operations.

Not within a stored procedure.

As I said, I didn't write it, I am having to dig into it as it suddenly blocked

the application.

To your other points - the sproc is not being called multiple times, I have

verified this.

I did execute it directly from Mgmt Studio and it did the same - it never returns for

minutes, meanwhile adding hundreds of thousands of records to the lpn table.

I already created a new procedure with the same code, just to be sure

that the sproc object isn't corrupt in some way. Didn't change a thing.

Good idea to put a WHERE condition.

There SHOULD not be a point trying to filter the records - based on what

the app is doing with it. Yes, if you run this twice, it will update these

records again. (The 'HR' is my rewrite, it is a parameter of the sproc

really). This is "allowable" in the application because t it won't ever

(presumably) call the sproc with the same parameter twice.

Jeff - yes I can put the FROM Addresses in the query, but it doesn't

change the behaviour. It also should not.

I'll solve the problem by rewriting. It still bugs me why on earth this

seemingly innocent code just overnight decided to mess up?