>
> The usual answer (which is in the FAQ) is to have the change to
> Table_Data insert a row into table_stats indicating that it added a
> value (+1) or removed one (-1). Periodically, run a procedure to
> aggregate the results.
> Updates will cause deadlocks unless they are serialized, meaning that
> only one transaction can change Table_Data at a time.
>

Thanks ann,

yes, i need to use an intermediate system (like a table) that will store
the change ...
mean more disk space, mean more memory, mean more slower :(

it's could be good if it's possible to have something like a "mutex"
inside the database that we can activate in trigger ...


or at least something like :

"Will the record is lock (dead lock) wait (xx seconds max) and after do
the query .. and
doesn't matter if the value changed between the time the transac start,
the time you
wait and the time you execute the query"


[Non-text portions of this message have been removed]