If the Transactional Integrity property’s value is NO, depending on the DBMS, different troubles can occur. Now, a detail of each one:

Oracle

It presents the inconvenience of closing the cursors that update once the ‘commit’ is performed. If you are working with Transactional Integrity in YES, it is possible to control this error avoiding including a ‘commit’ inside a For Each (see documentation of the property Generate FOR UPDATE OF clause of Oracle).
The topic is more complicated when we are working with TI in NO, because actually Oracle (like other DBMSs) does not deactivate the TI, but they enter in ‘Autocommit’ mode. This causes that the trouble appears more often because the ‘commit’ is automatically performed (not by GeneXus). This way, it is impossible to control in the application the moment it is performed, leaving a high probability that when a ‘commit’ is performed some updating cursor is opened and an error is caused.
The ‘work around’ is: changing the value of the property ‘Generate for update clause’ in NO, exposing us to the consequences mentioned in the documentation of such property.
The error in this case is: ORA-01002: FETCH OUT OF SEQUENCE

DB2/Common Servers and Sql server

As in Oracle, actually the TI is not disabled, but we enter in ‘Autocommit’ mode. But in these DBMSs when doing a ‘commit’ the cursors do not close, but the ‘locks’ are lost, so depending on the moment the driver performs the ‘commit’ an error can be caused or not.
In this case there is no ‘work around’ and the only solution is not to use this property in NO.

Informix and DB2/400

These DBMS really deactivate the TI so they do not present inconveniences.

 Summarizing:

 The property in YES allows managing correctly the transactional integrity, which is essential for the information to be correctly processed.

This property in NO has consequences that are, at first, unpredictable, depending on the particular characteristics of each DBMS. If the user understands that he has important reasons for using this property in NO, he must have clear the limitations his decision implies and a deep knowledge of the DBMS he is going to use for operating correctly with those characteristics (unpredicted cursors’ closing). ARTech is not in conditions of supporting the consequences of this decision.