Saving each modified row in a separate transaction

You can specify that the application save each modified row in a separate transaction. By default, without this setting, all modified rows are sent to the middle tier to be processed within a single transaction.

Saving one row per transaction can alleviate blocking problems in some forms. Whether the setting enhances performance depends on the complexity of a form's save operation and the speed of the network connection. Forms that require highly complex saves may benefit from the setting, especially if connection speed is adequate. Forms that require simple save operations are less likely to benefit, especially if the additional network traffic required in saving one row at a time slows the system.

The default behavior is that, if one row fails, the entire transaction is rolled back. When you save each row in a separate transaction and a row fails, all previous rows remain committed.

Note: If your form design requires that all modified rows be committed as a unit, with processing on the unit before and/or after a save operation, saving rows in separate transactions might not be appropriate. If an error occurs on a row, some rows might be committed and others not committed.

These forms save rows in separate transactions:

Job Orders
Job Operations
Job Materials
Current Operations
Current Materials
Customers
Customer Orders
Customer Order Lines
Vendors
Items
Purchase Orders
Purchase Order Lines

For instructions on setting this feature, see the topic on "Saving One Row Per Transaction".