Why do it this way? Personally, I'd just look for the records that the
user has actively changed, and attempt to save them to the database,
letting the database tell me about concurrency issues (for instance,
by verifying a "timestamp" column at hte point of save). Otherwise, to
ensure that no users change things behind your back you would have to
lock all of the data while checking, which doesn't seem very
efficient. Of course, locking the rows in question is a good idea
(TransactionScope or ADO.Net transaction). Also, by the time you have
fetched all the data from the database, updating the UI is the least
of your issues, so if you have the data, just update it. But if the
data is large, you shouldn't really attempt to do it this way
anyway...
There are also (in 2.0) database-oriented change notifications (works
best with SqlServer 2005), but I'm not a big fan of these... not sure
about the scalability... maybe I'm prejudiced though...
Marc
|