In a multi-user software application there is the possibility that more than one user is modifying the same data record at the same time.  Captools/net employs Borland Corporation's "Datasnap" (Borland trademark) technology to help deal with this possibility.  Basically, Datasnap tracks which records have been issued to users from the server.  Then when a modified record is returned to the server, it checks to see whether any other user has modified the same record in the interim.  If another user or automatic Captools/net process has modified the record, the second user is prompted with a warning as follows:

 

 

This dialog is intended to show you which fields in the record conflict with changes made by other users or processes since you loaded your records.  It also gives you choices on how to resolve the conflict.

 

You can either enforce your changes by selecting the "Overwrite" option, or you can Discard the conflicting changes you've made and refresh the data on screen to reflect the current values in the database, or you can defer the decision while retaining his/her data on screen.  The last option is temporary, since your local copy of the data will be lost as soon as you quit your Captools/net Desktop session.  This option is intended merely to give the user time to resolve with co-users whether they should select option #1 or #2.

 

You should not encounter this dialog frequently for several reasons.  First, the Captools/net Desktop will automatically save your local data and refresh your desktop periodically at the frequency specified in the Desktop preferences.  This process will also occur when you tab between table views or perform various Desktop operations which trigger computations.  The consequence of this is that you should almost always be working with "fresh" data, meaning that some other user or process will not have likely modified the data since your local data was loaded.  Secondly, in most organizations, the users of Captools/net will be set up such that each user has responsibility for different groups of accounts, minimizing the possibility of any overlap in account related records being edited.

 

Finally, for records which are "shared" by users, such as security records, record modification should be infrequent or handled by a single designated "data administrator".  Such "shared" records will in any case typically be populated and updated by automatic processes such as downloads and imports, and thus should not typically require manual editing in most cases.