Hi Calvin

>I have found the problem and I believe it is a dangerous bug. If the original form I am using is not subclassed - its parent is the generic form- then this problem does not occur. However, if the form I am using has a parent form that has optimistic row buffering set as the default then the only way I can find to keep data from being optimistically row buffered is to set each table in the data environment to have no buffering. If it is set to use the form default it is apparently picking up the default from the parent class , not the present instance of the form. This behavior seems to hold true in the VFP 9 beta also. I hope someone can confirm this and that this behavior will either be documented by Microsoft or altered to something more reasonable. Let me recap :
>
>Form A is a subclass of a generic data entry form.
>The generic data entry form is set to Optimistic table buffering
>Form A is set to Buffer Mode NONE
>Tables in the data environment of Form A are set Buffermodeoverride ='Use Form Setting (default)'
>Tables in the dataenvironment are actually in optimistic table buffering mode rather than the expected no buffering mode.

The DE instantiates before the form. If it sees anything on the form, it will be looking to the parent class of the form. I do not use form buffering at all. In a form with a single table/view that is providing a readonly source of data, I don't need any buffering. In a form with a read-write table/view that table/view needs buffering. In a form with at least one read-write table/view there are likely one or more readonly lookup/picklist tables. The lookup/picklists need no buffering. The read-write tables/views do. Seems to me, the number of read-write tables/views in a form will be less than the number of read-only in most cases. So, my form baseclass has no buffering and my scx forms which are derived from it don't either.

HTH