Hi,

Thanks for the reply, I tried this with 6million rows and I stopped the query once it hit 8 minutes and I have a quad core processor.

Admittedly I did not...

Oh one more thing....

Instead of perhaps an app_lock mutex am I able to somehow lock the table while I perform the seed and truncate operations? They are very fast so...

Hey all,

Ok after some thought I really don't think replication is correct for this scenario.

I have created a stored procedure which copies data using linked servers and runs as a...

Hi,

Using application locks (sp_getapplock, sp_releaseapplock) along with the SET based update SPROC shown last I have had a concurrent test run all night without fail, which is a first. It...

Another update...

I have got around the concurrency problem by using an application lock via sp_getapplock and sp_releaseapplock. I never even knew this could be accomplished in SS and I have...

Hi everyone,

Thanks again. I have gone back to the RBAR article, the reason I initially shyed away from this is the UPDATE recalculates every row which seemd a little OTT...

As an update also setting SET TRANSACTION ISOLATION LEVEL SERIALIZABLE appears to have potentially solved the problem I have now successfully run 50,000 concurrent transactions I will keep it executing.

UPDATE:...

Hi all,

Firstly, thanks for the responses

I have read the suggested article and although it is very informative it is geared towards calculating the total after the data is populated. I...

Now about to leave work, yeah thanks for the reply I will think about this and post again tomorrow. With the table design I have posted yes the only useful...