Hi Team,
   In a purely Local (Non Server) environment, and not using any Transactions per se, do the Pessimistic/Optimistic
Locking settings for a session have any affect?

Regards,
Ian

Ian

>    In a purely Local (Non Server) environment, and not using any Transactions per se, do the Pessimistic/Optimistic
>Locking settings for a session have any affect?

If multi user - YES, if single user yes but who cares.

The purpose of the pessimistic approach is that a record is locked when a user starts to edit it, if optimistic no such locking takes place. From the manual

Editing an Existing Row
The Edit method allows you to begin the process of editing an existing row in the dataset. ElevateDB
offers the choice of a pessimistic or optimistic locking protocol, which is configurable via the
RecordLockProtocol property for the TEDBSession assigned to the current dataset (see the SessionName
property for more information on setting the session for a dataset). With the pessimistic locking protocol
a row lock is obtained when the Edit method is called. As long as the row is being edited ElevateDB will
hold a row lock on that row, and will not release this lock until either the Post or Cancel methods is
called. With the optimistic locking protocol a row lock is not obtained until the Post method is called, and
never obtained if the Cancel method is called. This means that another user or session is capable of
editing the row and posting the changes to the row before the Post method is called, thus potentially
causing an EEDBError exception to be raised with the error code 1007 (EDB_ERROR_ROWDELETED), or
even error code 1008 (EDB_ERROR_ROWMODIFIED) if row change detection is turned on for the current
session via the TEDBSession RecordChangeDetection property. In such cases you must discard the edited
row by calling the Cancel method and begin again with a fresh copy of the row using the Edit method.

and

RecordChangeDetection
This property was added to allow the developer to specify
whether changes to a row will issue a warning exception
when the row is updated or deleted. In DBISAM this behavior
was not configurable and any changes to a row would cause
an #8708 (DBISAM_KEYORRECDELETED) exception to be
raised.

TL:DR

Last post wins is a possibility

Roy Lambert

Thanks Roy,
   Thanks for the clarification/confirmation, just wasn't certain.
   I have had Pessimistic locking set since the start.
Regards,
Ian