Starting with version OpenEdge 10.1A, in addition to transaction rollback, the OpenEdge database introduced a new feature to rollback to a savepoint. A savepoint is essentially a marker within a transaction that is recorded in the BI file.
In ABL, a request for a savepoint is made for each program block that could possibly be undone. Using these savepoints, ABL can request that the database rollback to a particular point. This implementation is internal and has no user visibility; its motive is to simplify transaction undo and possibly optimize database undo operations.
This feature can be disabled with the client startup parameter -nosavepoint, which restores the old mechanism (pre 10.1A). This parameter should not change the behavior of applications: if it does, then there is likely a bug with the savepoints mechanism and this should be reported to Technical Support for investigation with the appropriate evidence.
Please note however that the 4GL/ABL client use of savepoints was implemented as part of the Progress Development auditing work involved in sub-transaction rollback processing. The
-nosavepoint Client Startup Parameter was only added as a temporary safety valve for those cases where a bug may be caused by this implementation.
In other words, optimizations to the client sub-transaction rollback mechanism were made in 10.1A. In corner cases where a bug may be caused by those optimizations, Progress provides the -nosavepoint startup parameter as a temporary workaround which should be used until that particular bug is fixed. Hence, the -nosavepoint Client Startup Parameter is not intended to be deployed as a permanent solution. This is why it is not included in the standard OpenEdge documentation.
There was a known issue specific to the initial implementation of the 10.1A savepoints. In 10.1A the savepoints mechanism changes the semantics of record creation. When a record is created and a sub-transaction is opened, the record is created in the database immediately at the beginning of the sub-transaction. This is different than the behaviour in versions prior to 10.1A, where record creation is performed only under the following circumstances:
- the buffer goes out of scope
- an index entry needs to be created for the record
- the record is released with RELEASE.
This different behavior specific to 10.1A has been reported as a defect multiple times: OE00133589, OE00146112, OE00148173. The workaround in 10.1A is therefore to use the -nosavepoint startup option on client processes [_progres, _proapsv, prowin32, mpro ] to disables the savepoint mechanism altogether and reverts to the previous behaviour. It has however been fixed in 10.1B and no longer needed.
Note: As of OE 12.0, the -nosavepoint parameter no longer impacts the client session 
