Understanding Networks and Avoiding Update Conflicts -
Learn how working on a shared network is not the same as working on the Desktop.

Check us out at www.RepairShopPro.com

In busy shops, when more than one terminal is required, a network can be setup that will support multiple users working in parallel on one or more invoices at the same time. To do this, a shared database is used so all users on the network have access to the same information. This solves the problem of multiple users working in the system simultaneously, but it also creates some new unexpected problems that arise when two or more users are working on the same file at the same time. When users are working on separate files, there are no potential conflicts and the network acts the same as the Desktop In this tutorial, I will explain how working on a shared network differs from the Desktop and how to avoid potential conflicts.

Understanding how a Network Functions

When working on the Desktop, there is never more than one connection to the database. When a user requests a file, he has exclusive use of the file for the lifetime of the session. Conversely on a network, multiple users compete for the use of the same files. Since more than one user cannot be working on the same file at the same time, the server makes a copy of the file and sends it down to the users. The actual file master stays on the server. However, things get interesting when the time comes to save changes back to the database. Since a database can't record multiple changes at the same time, it serializes the changes in the order they came in. In other words, the last user to commit a change, keeps the change. This can lead to confusion when two or more users have the same file open.

Dealing with Update Conflicts

With multiple users working on the same file at the same time, there is always the risk of one user committing a change while another user is working on the same file. For example, if user A and B are working on the same file, and user A commits a change while user B is working, then user B's edit is invalidated because the underlying data has changed. To get around this problem, you can preview the server version by selecting "View Server Version" from the Preview menu, then select the "Take Server" command from the toolbar to retrieve the latest version from the server and release any changes to your local copy. Or you can ignore the changes and commit your local copy and overwrite the server version.

To keep you from having to remember to save changes, RepairShopPro automatically saves in the background so you may not know you have recorded a change. For example, when you open a service in RepairShopPro, the currently open invoice is automatically saved. If another user on the network has the same file open, then his changes will be invalidated. On a network, the last user to commit a change, keeps the change.

Discovering new Files Added or Deleted from the System while you were working

When a user on a network adds or deletes a file, it's only changed on the server. Other users on the network are not notified. Dynamically refreshing user desktops would require constant round-trips to the server looking for changes and downloading new files while users are working. The designers of RepairShopPro believe this would be too disruptive and add a lot of unnecessary network traffic that could really slow down your network. A better idea, and one most vendors adopt, is to allow users to update their desktops declaratively. At any time you can get the latest files by selecting the refresh commands under the Panels menu. This will instantly update your view.

Testing Two Users Working on the Same Invoice at the Same Time

If you would like to simulate a multi-user session to get an idea of what to expect, you can open two instances of RepairShopPro on the same machine. Try opening the same invoice in both sessions. Then commit a change in one session. Next re-open the same invoice in the other session by double clicking the invoice number in the tree. Notice the change is lost. This is because by re-opening the invoice, you committed a change to the database. Next try again with a new service, but this time select the "Take Server" command from the menu bar instead of re-opening the invoice to get the latest version. Notice this time, you will have the latest version. This is because you cancelled your edits and replaced your lcoal copy with the server version.

Check us out at www.RepairShopPro.com