Mark...

The WAIT option forces a transaction to stop processing if a conflict occurs with another transaction.  This in essence forces transactions to become single-threaded in a simplified manner.  It is also the default mode in Firebird.

The SNAPSHOT TABLE STABILITY option, which you suggested, appears to be overly restrictive for the majority of transactional conflicts. 

In the case of the initial issue, the developer required a technique to yield an error if an exception occurred in an attempt to delete a record when it no longer existed.  At least that was my understanding of the query.

This is a fairly standard issue when developing database applications that require concurrency at such levels. 

There is no reason why a transaction in this case cannot be simply set up to either yield an error so that ADO.NET can perform a rollback or do so in a manner that the transaction itself performs a rollback.

Either way, the internals of the Firebird database engine already handle such conditions as do most database engines or they wouldn't be able to process concurrency in the first place.  The need here is to simply tell the calling method what happened and why in the case of a failure...

Steve Naidamast

Sr. Software Engineer