Hi Jim:

OIC. The "cursor1" et al. name is just the name for the table...it's not a buffer name. What you have, then, is a situation where you are going to have to commit or revert the buffered changes to the table before doing the SELECT. There really is no way around it if you want the SELECT to grab all data including pending changes. Put a TABLEUPDATE or TABLEREVERT in from of the SELECT statement or run whatever save method you employ.


>
>I should have used the term "buffer" rather than cursor. The data environment creates a buffer in memory, (which the VFP PEM usually names "cursor1", "cursor2" and so on), which is the entity that is edited when buffering is on. What I am trying to say, not very well, unfortunately, is that I am using the table as the control source. VFP creates the buffer when I set buffering > 0. When I edit a control, the controlsource of the control, though set to a field in the underlying table, addresses all changed in the control's value to the buffer. The underlying table is not updated until the record pointer moves or a tableupdate() is issued. Meanwhile, I am SELECTing FROM the underlying table elsewhere, blissfully unaware that it does not contain the latest changes.
>
>regards,
>
>
>>Hiya Jim ---
>>
>>Ummmm...my first question back to you is why you're not just using the table as a controlsource instead of a cursor? Secondly, the dataenvironment will not create a cursor. VFP will insert tables into a DE if there are data-bound controls in the form with no corresponding tables and Private datasession.
>>
>>
>>>I just came across something that I am amazed I have not noticed before, and I would like to confirm it with the experts.
>>>
>>>Using a form's data environment, the controls on a form are actually interacting with a cursor created by the data environment. A cursor, cursor1, is created from table.dbf with the alias "table". Reading and writing is from/to the cursor "table", not from/to table.dbf.
>>>
>>>If buffering is off, any changes to the cursor "table" are immediately written to table.dbf, but if buffering is on, changes await one of two events: (1) moving from the current record or (2) a programmatic update, (or (3) are there others?)
>>>
>>>So far elementary. But...
>>>
>>>SELECT FROM does not operate on the cursor, but on the underlying table. So any changes one may make to the cursor are not necessarily reflected in the SELECT FROM results unless one first updates the underlying table.
>>>
>>>Which leads to the following inquiries:
>>>
>>>(1) Are my observations above correct?
>>>
>>>(2) Is there any easy way to force SELECT FROM to access the cursor "table" rather than table.dbf.
>>>
>>>(3) Am I an idiot for having failed to realize the above relationships before now?
>>>
>>>Any and all comments would be appreciated.
>>>
>>>regards,