> The Client started to add records to detail table.
> After he finishes his work , the program starts ( This could be a SP
> or Trigger or a code ) to update the sum table;

The process you describe will only work from the client. It is not
feasible to try and get a trigger of stored procedure to wait (AFAIK).

If you implement the process from the client app then it may be OK, as
long as the update-sums processing happens as part of the "save"
processing. That is; the user hits the "save" or "commit" button
which then attempts to perform the lock/calculate/post - and after
that process is successful a commit is performed.

Incidently you may be able to achieve the desired effect using cached
updates. They are not something I have used but it is a capability of
the IBO datasets. Perform the changes using cached updates and then
you attempt to commit all the changes together - it may save you some
code. (Using cached updates none of the changes appear in the
database until you perform a CommitUpdates call.)

The downside of cached updates is that the individual records dont get
validated at the server (where you presumably have triggers etc that
may be performing additional validation) until the updates are
committed. This sometimes means performing additional checks at the
client to maximise the chance of successful commit. This is one of
the reasons why I am not a fan of cached updates, but in circumstances
like this it may be appropriate.

Also: Remember to review what you are doing in light of the project.
Keep it all practical in light of the actual requirements. Understand
that it is only possible to offer very generic advice on this list.
For example; if your database has only a few users all in the one
office then the chances/problems involved in update conflicts may be
minimal, in which case there is little point in taking too much effort
to avoid a problem which will be rare and of little impact to the
users.

--
Geoff Worboys
Telesis Computing