>It sounds like your assuming Row Buffering is in effect. When using a grid bound to a table, your buffer settings are ignored, and the table is forced to Table Buffering.
In this the grid is bound to a view if that makes a difference, views are still a little new to me. One of the first things I checked was that buffering was turned on, and the view is setup for table buffering.
>
>Try using a routine like this to check for multiple changed records:
>x = GETNEXTMODIFIED(0, myTable)
>do while x # 0
> go x in (myTable)
> =tablerevert(.t., myTable)
> x = GETNEXTMODIFIED(recno(myTable), myTable)
>enddo
>
This seemed to make the occaisional uncommitted changes error happen less often, but I'm still getting it.
>Of course it sounds like the real problem is
why do you have a dirty buffer when you're in read-only mode. Are you modifying any data programmatically?
Yes that's the real problem alright, I posted this question to make sure I wasn't missing anything obvious before I spend the rest of this week and next trying to track down the dirty buffer. No I'm not modifying any data programmatically, but this particular bug is something I caused. This custom grid is pretty complex, and one of it's default behaviors is to remember the last active cell in the grid area, and return the cursor to that cell when user re-activates the page. The problem was, it remembered the last active cell when the user went to a new record. So I added code to reset a few properties when the user moves to new record, and if the page with the grid is active then I SetFocus() to the first field in the grid just to make sure I override this 'remember last cell' feature. Once I added the SetFocus call, then my TableRevert bug reared it's head.
Thanks for the suggestion, I'm going to try and find what's making the buffer dirty.
Roxanne M. Seibert
Independent Consultant, VFP MCP
Code Monkey Like Fritos