David,
One way to triangulate this problem is to have users sign off one by one and attempt your manual update until you find the culprit. Then, use shock and awe techniques to find out what they did most recently!

Either way, one person is stuck in the middle of updating. It almost sounds as if they're stuck in an update loop. Otherwise, requerying the view would pick up the latest changes, after which a new tableupdate should succeed.

Hope that puts you on the right track,
---J

>I have a client with about a dozen users. They are reporting update conflicts when trying to save certain records. They are getting the standard MM "Another user..." message. The application then crashes.
>
>Once this happens, they cannot ever edit that record without getting the same message, and a crash.
>
>When I try to manually update the corresponding view directly from the VFP command window, I cannot - tableupdate() fails. The only way I've been able to "release" the record is by kicking everyone out. Then the problem seems to go away.
>
>It's almost as if someone's machine is somehow locking the record, and not releasing it.
>
>I'm having no luck reproducing the error in my production environment. What's worse, the problem is so sporadic that it's been impossible so far to reproduce.
>
>I am quite confident that only one user is ever working on that one record, because each user is assigned a number of specific tasks which don't overlap with anyone else's work.
>
>I'm using VFP 7, MM 7, with a VFP backend. The backend sits on a Win2000 server.
>
>Any thoughts would be appreciated.
>
>Thanks,
>
>David