4 Replies Latest reply on Jul 28, 2017 4:14 AM by amsc

    Synchronizing Data (for Multiple Users)


      Hi everyone,


      I have a situation where multiple people are editing price data.


      They have a table of prices (which I pull with ExecSQL into a virtual table for each user) with identical rows, as illustrated by the following simple example:









      Suppose User1 changes PriceA, and then saves/commits the record.  Meanwhile, suppose User2 has the table of prices open at the same time as User1, and then edits PriceB, after which she save/commits the record.


      The problem is PriceA gets reverted to the original record before User1 made the change, as both PriceA and PriceB were fetched before any changes.


      Is there a way/technique to have USER2's table updated with the updated PriceA when USER1 finishes editing and saving it?  I would prefer to not have both users editing the table of prices directly(i.e. I want to keep the virtual table approach)?


      I guess my question relates to whether it is possible to know via script if User2 is concurrently editing the prices - at least alert User1 that someone else is working on the prices as well?


      Thanks as always!


        • 1. Re: Synchronizing Data (for Multiple Users)
          Dave Graham

          You might want to talk about why you are using a virtual list for this purpose. There might be a better way.


          That said, here are some options:

          1. Grab the mod count using Get(RecordModificationCount) when you build the VL. If the user attempts to edit the price, compare it with the current mod count to see if another user changed the price; then warn the user and refresh the VL.
          2. Try to open the price record before allowing the field to be edited. You can do this with SELECTOR CONNECTOR approach so it doesn't interfere with your virtual list. If the record is in use (error 301) don't allow editing.



          • 2. Re: Synchronizing Data (for Multiple Users)

            I've approached this using "record checkouts"fields that lock the record from editing. For example, user A selects the record for editing.  A field labeled "Lock" is populated with his account ID. if user B attempts to edit the record, the user is notified.  The lock is released when the editing window is dismissed, either through a record save or closing it.  User startup and shutdown scripts quickly scan for any "stuck" locks and a supervisor can release locks if needed.

            • 3. Re: Synchronizing Data (for Multiple Users)

              Oh, and I forgot to say, records are shuttled to a temp table for editing. 

              • 4. Re: Synchronizing Data (for Multiple Users)

                Just read through the selector-connector approach.  Quite clever!  That method could reduce a lot of the overhead as compared to record checkouts.   Thanks!