ElanKathir:
I'm not sure what you are asking. Different applications have different
concurrency ramifications. For instance, take a Health information System
App. If two users were working on admitting a patient and both grab a given
record. Person 1 discovers the patient is violently allergic to something
and records it. However, Person2 check the record out at the same time and
submits the update later. If there weren't concurrency checks, and you used
Last In Wins, then this fact would be overwritten which could have terrible
consequences. In another instance, you might want the exact opposite to be
the case, say in an instance where you have an attending phyisician who
monitors residents. Say he/she pulls the records out in the morning the
same time as the resident, and then resident makes some changes...however,
the attending gets called out and comes back later in the day . He has the
updated patient chart and ultimately makes the decision of how things should
be. In this case, it 'might' be ok for someone to overwrite existing
changes.
It really depends on the application and Concurrency is an issue that
concerns the RDBMS and the business rules - and as such, isn't really an
ADO.NET issue, rather, it's up to the programmer and those that make
business rules to determine how concurrency should be handled and it's only
ADO.NET's job to ensure those rules are followed.
Also, the command object doesn't enforce Concurrency decisions, it merely
submits updates/inserts etc. The DataAdapter, CommandBuilder or your own
update logic is ulimately what determines how you handle concurrency.
What specifically is the scenario you are encountering? I can probably give
a much more precise answer if I knew this.
HTH,
Bill
