Changing the same record in DB lazarus / 63-Database ---------------------------------------------------------------------- LemonParty · 2026-04-07 17:13 Hello. Let's say we have 2 connections to DB. The first user opens table X and changes record Y in it, at the same time another user opens this same table and changes record Y. Then the first user commit transaction and then the second user commit transaction too. There will be an error or maybe exception? What will happen? ---------------------------------------------------------------------- Zvoni · 2026-04-08 06:20 Quote from: LemonParty on April 07, 2026, 07:13:45 pmHello. Let's say we have 2 connections to DB. The first user opens table X and changes record Y in it, at the same time another user opens this same table and changes record Y. Then the first user commit transaction and then the second user commit transaction too. There will be an error or maybe exception? What will happen? This is about Isolation Levels. Read here: https://en.wikipedia.org/wiki/Isolation_(database_systems) As to what's happening? Depends on the Isolation-Level and the DB in use ---------------------------------------------------------------------- egsuh · 2026-04-08 07:15 Zvoni's answer would be precise, but probably the lastly committed change will remain stored, in general cases. ---------------------------------------------------------------------- Thaddy · 2026-04-08 07:42 The theory behind it is ACID. https://en.wikipedia.org/wiki/ACID Not a long read and a solid explanation. Most distributed databases have out-of-the-box support for that. Some databases need something like a trigger, though, keeping track of multiple read access and generating a warning on commit that the record is being edited elsewhere. I once wrote something like that for Sqlite ( a server-side user defined function that keeps a reference count in a separate table) which lacks that, because Sqlite is by design not a multi-user database. It may be that mORMot already has something similar available, though? In its simplest way, egsuh is right: simply all commits are accepted, but that is not how distributed databases usually work, since the commits can be conflicting, so care needs to be taken, otherwise the database may be permanently in a conflicting state for that record and that is not good database management. You need write locks and a trigger, usually this is built-in in some form. ---------------------------------------------------------------------- Zvoni · 2026-04-08 08:48 As to SQLite: "Default" is, if you have a "pending" Transaction (Not commited or rolled back), trying to commit (or is it "starting" the Transaction? Don't remember) your second Transaction results in an Exception "Database is locked" ---------------------------------------------------------------------- cdbc · 2026-04-08 09:55 Hi With SQLite3: What I usually do is: keep datasets in memory (like a ClientDataset), e.g.: TBufDataset, maybe then I write a middle-tier that funnels / sequences the changing of data to database one at the time, so _no_ locks... Additionally one could use a lock-file with the 'tablename-recID' currently being in transaction, so that the user gets a warning, if he tries to change that specific record, this ofc. if we're talking 2 different processes, otherwise one could do it in memory... Just my 2 cent's worth Regards Benny ---------------------------------------------------------------------- jcmontherock · 2026-04-08 10:00 DB contained in one file are not done for multiple, several and simultaneous access to the same data. ---------------------------------------------------------------------- cdbc · 2026-04-08 10:04 Hi I agree, it's usually not worth 'the mountain of fiddling' needed, when you've got several good multi-user-databases available... Regards Benny ---------------------------------------------------------------------- LemonParty · 2026-04-08 13:42 Thank you for answers. This two articles https://en.wikipedia.org/wiki/Isolation_(database_systems), https://en.wikipedia.org/wiki/ACID have an explanation about such situations. ---------------------------------------------------------------------- Tomu · 2026-07-22 17:13 One strategy is to have a last_updated timestamp field in the table - perhaps set by a trigger. Then when you load the record to be edited hide the  last_updated timestamp field. But when you save the record UPDATE MyTable (List of fields to update) Values(...) where last_updated = what was read when loaded. Then if SQLQuery1.RowsAffected = 0 you can tell the user to reload the record and try again.