Quote:
I'd love a way to avoid using the database as the deciding factor, but I understand if there's no other way to do it.
ok .. but thats what databases are good at. You could write a similar scheme yourself - but at the end of the day, I doubt you would end up with something comparable to what the DB offers (that's not being nasty or disrespectful to you (*) - thats acknowledging the shear amount of work that has gone into Oracle, MSSQL etc)
Lets say every row in your customer record has a 'id' field that
- is blank if the record isnt being edited by someone else
- has the terminal/user id of the terminal/user editing the record
It's still possible to get the equivalent of a 'race condition' in threading terms between when you set the 'id' field to the terminal/user to say 'this terminal wants to update the record' and when another request might say 'I want to do something to that record'. If you're using stored procedures, auditing and logging, then should an inconsistency arise then you can resolve it, but I still think 'let the db do what the db does' should be the rule of thumb - unless of course, the db doesnt offer any form of row locking ...
The other issue is under duress, I think I read even MSSQL might not honour the request.
my 0.02c worth
(*) unless you work/worked for any of the aforementioned companies