> [GWM] I am preparing the stored procedure and assigning the value of the
> balance change to the Param of the procedure. And, this SP is using the
> exact same transaction as the queries.

You are supplying the amount to change the balance by? SO
the balance figure should not be blocked because it is never
updated directly?

Each transaction will create a copy of the target record,
and the commit logic should ensure the right copy is used at
the right time. If two transactions are looking at the same
record with the balance in, then the two copies will have
the same value stored, and a change to the second copy
should be blocked when the first copy is updated and
commited.

> [GWM] I don't understand what you are saying. What you have indicated is
> exactly why I am using the SP. I am simply sending the balance change to
> it, and the server should be taking the client's current balance and
> applying the change to it...regardless of how many people are sending
> balance changes at the same time. What I didn't want, was to load the
> balance with a query and change it based on the value at the time is was
> loaded. That, to me, would create the scenario you are describing.

I have to admit to not understanding the multi-generational
bit of Firebird totally, but I have had similar sorts of
'missing' updates and these I tracked to trying to update
the same value from two sources. The fix that worked for me
was to get the BeforeInsert and BeforeUpdate triggers to
ammend the value in the other table, rather than trying to
change it myself.

> [GWM] I guess what I don't understand is why all aspects of the query is
> committing except for the SP. And, remember, this happens very rarely,
> but it does happen and I need to solve it.

IBO has been much more stable than BDE ever was in this sort
of situation, so something is droping through a hole.

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services