As I'm sure you know, there is no SAVE command in VFP and I think that when someone says "save", most developers will assume that person means "perform a TABLEUPDATE" (assuming buffering is in use). The common meaning of "save" is that the changes are committed to the table and won't go away unless the are changed or deleted later. When I said "save" in my original posting, referring to someone who had suggested that on another web site, I believe they were specifically saying they did a TABLEUPDATE after each change to a record in a child table. This method prevents you from saving or canceling the changes as a whole. Perhaps I should have said they were specifically doing a TABLEUPDATE, but I was thinking my use of "save" would be understood. In hindsight, I should have been more specific. And when you said "save", I thought you meant TABLEUPDATE, but I now see that you are talking about ensuring that the values from a change are stored to the buffer (and, of course, this is a common issue with controls - you have to "manually" get the value of the control to the buffer if you don't exit the control - LostFocus doesn't fire - but then click on a toolbar button). So hopefully we are on the same page now.

At present, I am not comfortable with the workaround that you suggest. First, the fact that this is so unpredictable would indicate to me that it's a VFP bug, not a "by design" issue. Second, the problem that I am seeing (and that I believe was also reported by the person originally posting thread #787471) is that the error occurs sometimes during a REPLACE on the view that is displayed in the grid, but not always. My error log shows me that it also occurs on a REPLACE in the form's main table (which is using optimistic row buffering and is not diplayed in a grid on the main page, but is displayed in a read-only grid on the List tab), so this would go against your theory that this is related to a grid not being aware of the changes made to another, noncurrent record and the grid becoming "confused."

And it does make for crappy looking code when you're constantly having to insert kludgey "move the record pointer to make the changes stick" code. Plus, then you will often have to move the record pointer back to that record. So it's . . .

REPLACE <whatever>
move the record pointer
move the record pointer back

Well, that is cruddy-looking and it shouldn't be necessary, but I'd be willing to put up with it if I could somehow reproduce the error and then see that the code, however kludgey, fixed the problem (and if it was happening as you explained, which sometimes it is and sometimes it isn't). But I'd also hope (expect?) that MS could fix this problem.

Thanks for all your replies,

Russell


>>I think you're misunderstanding the situation. The user has made changes (perhaps quite a few) to a child table (a view) that is displayed in a grid. They then attempt to save the record and during the save it says that they can't save because "the cursor cannot be modified because it contains uncommitted changes." Well, yes, it does contain uncommitted changes. All of which need to be saved, but instead I get this error. I can't TABLEREVERT because the user has made changes with the intention of saving them, not reverting them. It's like saying "sorry, you've made changes therefore I can't save your changes - you'll have to revert your changes, make them again, and then maybe I'll be able to save them next time."
>>
>
>Hi Russell,
>
>I am afraid you misunderstood the error message "the cursor cannot be modified because it contains uncommitted changes.", it has nothing to do with presence of changes waiting for the TABLEUPDATE. And the workaround "make sure the record is saved" has nothing to do with executing TABLEUPDATE.
>
>I replied to your message just because you stated the following:
>>
>saving prior to inserting records. Well, that's not workable. I need to be able to give my users the ability to save or cancel a tranaction as a whole and this "workaround" prevents that.
>>
>
>And I don't see how the workaround would prevent you from "be able to give my users the ability to save or cancel a transaction as a whole ". If you are using table buffering, the workaround will not prevent you from that. Even if you save the record, it'll go into the table buffer. If later you want to send it to the back-end along with some other changes, fine, execute TABLEUPDATE(). If later you want to cancel the modification, execute TABLEREVERT(). There is an ability to save or cancel the transaction as a whole.
>
>Thanks,
>Aleksey.