On Wed, Feb 3, 2010 at 12:35 AM, Ashley Sheridan <ash@xxxxxxxxxxxxxxxxxxxx>wrote: > It's the reason transactions exist, to prevent things happening like this. > When you have two actions where one is dependent on the other, unless you > have a way to tie them together so that they can't be broken, you run the > risk of collisions. > > Yea, and i wish they'd standarized features like that across sql servers. But they haven't, so i avoid them like the plague. Whatever dependencies and threading problems might arise, there's always the principle that says: If it doesn't work whlie it should work and threading-timing problems are the only possible cause, then by delay by a random timeperiod and retry the query. In really advanced cases, one can work with last-modified timestamps and/or build up a simple sort of work-queue (also in a table), whereby threads inform each other of the status of their computations.
