Mike,
Thank you for your reply. As I read it it makes perfect sense. However, at the very least the way this is setup is misleading and I would go so far as to say it is a bug. I set my form class up when I was just learning VFP and have been using it for 4 years. This is the first time I have had any problem with it. It may have not been the wisest thing to set the form to use optimistic buffering but if I override that in the dataenvironment I would expect it to at least tell me I cant do that or generate some form or error along the way.
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.
A problem is a problem only as long as it has a possible solution. Lacking that, it becomes a FACT!