How can we help you today?
Cannot update row. Concurreny error
Firstly in code, but also with the VistaDB Data Builder following exception occurs after this DML:
UPDATE [PkBlocks] SET [xx] = yyy WHERE [TableName] = 'ProjectData.NET'
has been executed. (Consider that no other DML statement has been executed before)
To ensure no process is currently accessing the DB, I did restart the PC and opend the VistaDB Builder right after a reboot. Same result.
Are the transactions somehow written into the db file? If so, how am I able to "delete" those pending, but deprecated transactions?
Yes, a transaction that was never committed or rolled back can leave an "orphaned" transaction--with any rows that it modified left in an indeterminate state in the database. Any other connection attempting to modify the same row(s) will get a concurrency error because the state of the prior transaction can't be determined. In a NonExclusive environment there's no way for it to know whether the other connection is still open or has left it orphaned.
If the connection is properly closed then a pending transaction should get automatically rolled back, so--other than when it is actually still pending in the open connection--the main way these "orphaned" transactions can occur is if execution is killed without executing the usual .NET cleanup code to dispose the connection and transaction objects. This can typically happen by stopping in the debugger, by hard-killing the process, or by loss of power to the machine. It should be rare for this to happen in production--although if your code does not ensure proper cleanup/disposal of open connections upon exit (or exits in an unusual way that bypasses it) it may also occur more easily even in normal use.
To remove the orphaned transactions the database needs to be Packed. This requires an Exclusive connection, so there can't be any transactions still pending and any it encounters can be assumed to be orphans and rolled back since they were never actually committed.
It occurs to me that any Exclusive connection could similarly assume that any unknown transaction is an orphan and should be rolled back, even without a pack. It doesn't currently support doing this, but that's something we should look into.