Record remains locked when cancelling or saving with no changes

[gamehoist]

I notified you of this problem with version 3.3 of DOA. You stated that it would be fixed in the new release of DOA but this doesn't seem to be the case.

We are now using DOA 3.4.2 for Delphi 5 and have run into the following problems:

Scenario #1:
- User A puts a record in edit mode (DOADataSet.Edit)
- User A cancels the record (DOADataSet.Cancel)
- User B tries to put the record in edit mode and gets error message that the record is still locked.

Scenario #2:
- User A puts a record in edit mode.
- User A doesn't make changes to the record but saves anyway
- User B tries to put the same record in edit mode and gets an error that the record is still locked

Please let me know if this was supposed to be fixed in the current release of DOA.

Thanks,
Eric Dye

 

[Marco Kalter]

This is fixed, except in the situation where you are using CachedUpdates and have set LockingMode to lmLockImmediate. If this is the case then the 2 scenario's are more or less correct, though a bit unfortunate. Are you using CachedUpdates and lmLockImmediate?

------------------
Marco Kalter
Allround Automations

 

[gamehoist]

Thanks for the help, Marco.

I am using an immediate lock but NOT cached updates. The documentation for DOA states that

lmLockImmediate When the user starts editing a record, it is locked and a check is performed to see if it has been changed. The lock remains until the user posts or cancels the changes.

It is behaving like the lock isn't releasing unless I make an actual change and post. Can you explain what you mean by "...more or less correct". Thanks again.

 

[Marco Kalter]

If CachedUpdates = False, then maybe you have set CommitOnPost to False?

I wrote "more or less correct", because the behavior is as designed (you can't rollback to undo the lock if the actions are part of a bigger transaction, and you can't rollback to a savepoint because you don't know what has happened in the transaction between Edit and Cancel), but it is not ideal. If CachedUpdates = True or CommitOnPost = False the lock may be part of a bigger transaction.

------------------
Marco Kalter
Allround Automations

 

[gamehoist]

CachedUpdates is FALSE and CommitOnPost is TRUE. Is there anything else that could be going on?

I can't imagine that the component was designed to work this way.

CachedUpdates=False
CommitOnPost=True;
* Put record in edit mode, make changes (or don't, doesn't matter), cancel, and the record remains locked.
* ..or put record in edit mode, don't make changes, Post, and record remains locked.

Is anybody else having this same problem with immediate locking or am I just lucky?

Thanks again for your help, Marco. I look forward to your reply.

Eric Dye