Locking Behavior and Transaction Mode
On Microsoft SQL Server and Sybase RDBMS servers, a record cannot be read if it is already locked by another user. This may cause unwanted behavior in a USoft application.
You can influence this behavior in two ways:
The Transaction Mode property is an application-level property.
*transactionMode : BatchManipulation
The default value is the ImmediateManipulation transaction mode.
With BatchManipulation transaction mode, if the transaction fails, a rollback is sent to the RDBMS. Immediate feedback is returned for referential integrity, and cascading update and deletes are executed normally, even if the row has yet to be stored in the server.
Restricted update and delete, unique keys, and foreign keys are all checked both at store-time and at commit-time. If a commit is refused, it will appear as an error message (rather than in the transaction window). Additional fields will reflect updates at commit-time and, if possible, at store time. Re-querying data that has been stored (that is, saved locally) but not committed is possible, except for the following restrictions:
This timeout can be changed by adding the following resource setting to the command line, using the -xrm option:
In this instance, the result is a timeout of 60 seconds.
Increasing the timeout has the advantage that timeout error messages do not appear too soon, and stop the transaction too soon. A disadvantage is that too long a timeout may cause a user to wait too long for a locked record.