Alan McDonald wrote:

>
> But a transaction started by another user before the sum transaction is
> started and seemingly intent on updating a record to be summed but not
> committed until after the summing and deleting is committed will ... ahhh
> hopefully you're getting my drift... will either cause an exception on
> update or block the delete or just not update since the record doesn't exist
> anymore.

There are two definitions of "safety" in this case. One is
that the summation will accurately reflect the contents of
the records that were read and deleted. The other is that
the procedure is guaranteed not to conflict with other
concurrent actions.

The first is possible, assuming your using concurrency/snapshot
transactions - not read-committed, the summing and replacing
can be done safely with other transactions active. It may get
an error, but it won't get a wrong answer. If some other
transaction modified one of the records being summed before the
delete, the delete will get an error. If the delete has occurred
and the other transaction tries to update the record, it will get
an error.

If the definition of safety is that the procedure can run
with no chance of errors, then it must be run without other
transactions modifying the same data. A gateway record could
be the solution - something you have to modify first before
making changes to the actual table data.

Regards,


Ann



Regards,


Ann