Concurrency...

  • I understand the concept, and have wrapped all my sp's actions (insert, update, delete statements) in begin tran, commit, and that should make sure there are no gridlocks.... but... I'm wondering how best to handle the 'disconnected' aspect of .NET? ...

    I mean:

    user a selects an item to work on, now has a local copy of all the information, so does user b. user a makes changes then goes to update...at this point the tran/commit stuff takes over,....but now user b's information is out of date, and when b updates her work it may/may not overwrite changes from user a.

    Since the nature of this app says they won't, there is the outside chance of that happening. It's been a REALLY long time since I've worked on this type of multiuser app and I'm just wondering how others may handle this kind of situation?

    Do I keep a little table of who's working on what? that would allow me to notify users if they select a currently open item? To I row lock user a's item and keep it locked 'til they're done (UGLY)...

    Any ideas will be greatly appreciated...I'm quite willing to give up first born or whatever...

    Michael

  • Have a look at the following and see if it gives you any ideas.

    http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=169&messageid=362233

    -Luke.

    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • Thanks for the pointer Luke. I guess the timestamp thing is the way to go, along with a 'updated by' field. This place is small enough that they can bicker over the cube walls as to who has to redo their changes!....

    thanks michael

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply