Craig,

One possible approach not mentioned in this track (at least I haven't picked it up) is the one I generally use in my enterprise applications: I call it "User Behavior Modification". To avoid the change tracking mess, I use pessimistic locking with a timeout. If the user goes to lunch or Timbuktu whilst in the middle of a transaction, the system waits for (an administrator defineable) time, then rolls back the open transaction, closes the program and creates a log entry which the lazy bum sees the next time he/she logs in. The note gives some details about the incomplete, rolled back transaction as well as the reason: "You left this transaction open for too long, and the system took the appropriate action." Furthermore, I apply some peer pressure by telling users who need to edit locked data who has it locked and for how long, and how long until the row will be automatically made available again if the locker (<g>) doesn't do anything about it. I generally keep the locker anonomous for a reasonable period of lock time, so that peers don't start nagging their colleagues who are being responsible and trying to get through an editing task in a reasonable time frame.

This is more social than software engineering (after all, I have Master's degree in Sociology). The program simply tries to make users understand that actions as well as INactions have consequences, and that they will lose some work and/or hear from their peers if they are not being good data citizens. It has worked quite well in my applications, and i find that the users generally become compliant in a very short time. With proper messaging, the lazy or distracted users also come to completely understand why they can't just leave a transaction open for a long period of time and thereby inconvenience others.


Pertti


>I've added change tracking to my research list. This is a great discussion. Thanks for keeping it going and for steering it in this direction.
>
>>I feel sure I've already said this, however: it was stated elsewhere that datasets are rendered obsolete by entities. I decided to investigate. I found that dLinQ entities have no change tracking as soon as you disconnect from the DataContext, which you have to do to cross a tier. As you note, datasets need not suffer this limitation. Therefore why would you consider entities over datasets in April 2007, unless you can stay connected. Clearly datasets are not obsolete. MS (or at least a MS employee) has acknowledged the issue elsewhere (see previous post for link) and says it will be addressed.
>>
>>I have no idea why people have interpreted this as "NET can't do change tracking". I'm wondering whether I'm the only person who has actually looked at LinQ and "gets" the distinction.
>>
>>Since then I've learned that even those who advocate datasets apparently don't use the change tracking functions. So, I've tried to find out how they manage change tracking. One well-known author uses SPs that update every field every time and has rolled his own pessimistic locking system to avoid change tracking altogether. I'd be interested to hear your opinion of that. Why aren't these people passing datasets and using change tracking so they can reuse classes in stateless apps rather than writing something new? Is use of SP more important?