| Ralph 2004-05-04, 11:42 am |
|
"Brijesh Shah" <shah_brijesh@hotmail.com> wrote in message
news:%23XV6z%23gLEHA.1192@TK2MSFTNGP11.phx.gbl...
> Thanks for all the responses.
>
> There are bit fields and I have seen the knowledge base article before but
> the problem is this behavior is not consistent. It happens at our client
> site but we are not able to simulate it at our end with the same database
> structure.
>
It is not uncommon for this type of problem to vary across systems. You are
actually lucky it was consistent enough to be caught at all.
Assuming you are not creating this problem from a complex script (in which
case you may need to repair the SProc), but from separate transactions - You
will likely need to redesign how you are updating this data by removing the
data to separate records that can be sequenced upon recall, or by creating a
queue - using a singleton or COM+ messaging. (Schemes that appear to resolve
the probem by altering timing or locking will only mask the problem to have
it reappear later perhaps even more mysteriously.)
Appreciate that all forms of multiple access RDBMS "locking" schemes or
transactions only guarantee data integity - never concurrency.
HTH
-ralph
|