On 29-09-2023 18:18, Steve Naidamast wrote:
> As Mark suggested, the "RETURNING" clause does in fact work and that is
> what I had used before but couldn't remember that. and since I am
> developing with Firebird Embedded, I do not have to be concerned with
> multi-user issues.
Even with embedded you can have multiple concurrent connections and
multiple concurrent transactions. The fact you use embedded in itself
does not somehow prevent concurrency within that single application. And
if you use a firebird.conf with an appropriate value for `ServerMode`,
multiple applications using embedded can access one and the same
database, so then you can have concurrency from multiple applications,
and concurrency from multiple connections (or multiple transactions) in
each application.
> However, as to the issue with multi-user platforms, if it is being found
> for whatever reason that the "RETURNING" clause is returning incorrect
> data due to multi-user operations then in this case, the developer will
> have to implement a write-lock thereby queuing up user inserts allowing
> each one to occur on its own and in isolation.
RETURNING, if used in combination with a primary key generated using an
identity column or a sequence and trigger will not have a concurrency issue.
The concurrency issue I was referring to has nothing to do with
RETURNING, it was in response to the example produced by Mario to use
`Select max(PK) from tableX` and then incrementing by one to produce the
next primary key.
> This should be able to be accomplished using a transactional task
> instead, since transactions are suppose to be isolated from each other.
> However, if this method is not working than the write-lock technique, I
> just mentioned, will have to be used.
If you use an identity column or a sequence + trigger, then that is
already covered.
Mark
--
Mark Rotteveel