>But, still not understanding enough about Michel's system, I'm not sure locking at this level will resolve the issue. True - it will guarantee that the hit does not receive an inconsistent or out of date version of the data on entry. But it does not prevent the reverse - data being changed on another thread before the hit exits. The only way to do that would be to hold a lock on the 'hit' thread until it completed - obviously not practical for a IIS site ?

I am trying to avoid the locking. The resolution proposed by Gregory to go with a copy, thus to initialize into a Temp and then assign the new value should resolve the issue. It is just that the copy is not working at the designer level complaining about "Value of type 'Framework.Framework.TablesTemp' cannot be converted to 'Framework.Framework.Tables'.". But, I think I found why. I will reply to one of his messages for the follow up.