Wie het laatst opslaat heeft gewonnen. Zo werken de meeste database applicaties. En zo is Firedac standaard ook ingesteld. Er wordt niet gekeken of de gegevens in de tussentijd veranderd zijn. In veel database applicaties wordt hier niets mee gedaan. Soms kom je applicaties tegen met een uitgebreid custom made systeem om dit probleem te tacklen. Maar Firedac heeft een optie waarmee je dit eenvoudig kunt voorkomen, namelijk de UpdateMode in de de UpdateOptions.
Er zijn drie mogelijk instellingen die dit probleem oplossen via de WHERE clause van de update query.
Als het niet lukt om een update uit te voeren, dan raised Firedac een EFDException. De afhandeling hiervan is dan wel naar eigen inzicht. Het voorkomt echter op een eenvoudige manier dat er – tot verbazing van gebruikers – gegevens worden overschreven.
Natuurlijk kun je dit probleem ook met locking oplossen, al zijn er wel verschillen. Bij locking ben je afhankelijk van wat een database hierin ondersteunt. Het nadeel van locking is ook dat niemand anders mag schrijven in de tabel of het record, zolang jij het gelocked hebt. En afhankelijk van je instellingen zelfs niet eens lezen. Dat geeft vaak situaties waarbij gebruikers een slechte performance ervaring hebben, omdat queries staan te wachten tot records worden vrijgegeven.
Met de UpdateOptions.UpdateMode kan dit op een relatief eenvoudige manier in een bestaande applicatie geregeld worden. Als je de optie instelt op connectieniveau, dan geldt hij standaard voor alle commands, maar je kunt ook beginnen om dit per query of table in te stellen. Hierdoor is een geleidelijke aanpak ook mogelijk.
Contact