Newsgroup Nugget: Row-level locking with FireDAC

Posted by on in Data

Here is a recent newsgroup post asking about Row-Level locking using FireDAC to talk to SQL databases. Enjoy!

Emery asks:

I’m working on a project right now that’s presently using FireDAC to connect to PostgreSql, but we are planning on expanding the possible backends to include MS/SQL, MySQL and Oracle as well (with possibly other, not yet identified, alternatives as well). PostgreSql may or may not be in our long-term plans.

One of the single most important requirements that I have is the ability to perform row-level pessimistic locking as effortlessly as possible within the application. I would like to, if at all possible, have many queries read the database asserting minimal locks and have specific queries assert atomic row-level locks on a single record identified by the primary key that will prohibit other users of the same system from writing to the same record at the same time (and, strictly as a matter of convention, from adding or deleting child records of the locked parent records as well). I do not want to block other users from reading the locked data with the understanding that a user will be possibly seeing stale data at the time of the read).

What specifically must I do to do so with your components? Are any of the mechanisms dependent in any way on the specific backend that I am connecting to (that is, in terms of the SQL that I must create on the front-end in order to connect)? In other words, can I safely have the exact same SQL used to connect to any of the above backend databases or will I have to generate SQL that is dependent on the specific database to which I am connecting? If the SQL has to vary, can you identify for me what the SQL must look like for each of the above backends?

Please provide as much detail as possible. The right database connectivity solution is terribly important. I want to give FireDAC the full consideration it deserves in making the right decision for this project.

Thanks, Emery Galambos


Dmitry replies with the relevant FireDAC DocWiki links:

All of these properties control only automatic data editing: FDQuery.Edit / Post. They do not have influence on FDQuery.ExecSQL('UPDATE ...'), etc.

With best regards, Dmitry


Gold User, Rank: 1, Points: 2466
David Intersimone (known to many as David I.) is a passionate and innovative software industry veteran-often referred to as a developer icon-who extols and educates the world on Embarcadero developer tools. He shares his visions as an active member of the industry speaking circuit and is tapped as an expert source by the media. He is a long-standing champion of architects, developers and database professionals and works to ensure that their needs are folded into Embarcadero's strategic product plans. David holds a bachelor's degree in computer science from California Polytechnic State University at San Luis Obispo, California.


Check out more tips and tricks in this development video: