Bill-

>The weirdest thing, right after I posted my question about the form not
>displaying the correct record,.... I went back, launched VFP5
>ran the form again, and it seemed to work just find.

Great.

>I must say, I find all the various settings confusing.

May I suggest Effective Techniquest for Application Development as being a good resource for clarifing these concepts?

> I didnt askfor a private datasession, reasoning that it is a single user app,

Private or default datasession doesn't have anything to do with single- vs. multiuser, since the data is relative to the current session of your app. The reason to have private data sessions is so that forms can act independently of one another on data. FWIW, I use private datasessions *almost* exclusively. Exceptions are for child forms that gather some detail infor for the main form, for example.

>I set to false anything to do withopening tables, closing tables, in the data environment

If you are using the default datasession than I doubt you need to be doing anything with the downstream DEs.

>And I set theload data on initialization thingamajiggy to false, reasoning that
>the fields should just display the data that the cursor is positioned

From the help: NoDataOnLoadCauses the view associated with a Cursor to activate without downloading data. Available at design time; read-write at run time.

Are you even using local or remote views? Or are you using tables?

>I realize there are many different ways to accomplish what I was
>attempting with this, but I just felt like understand how all these
>various data environment/form settings and bound controls work.

Yes, it's very important, I agree.

>The same learning desire was the case for my earlier post regarding
>how to pass a custom property from a parent form to a child form,
>and receive it back changed by the user. Someone from another VFP list
>serve told me that was an awkward way to do things, passing properties
>between forms,

Right, better (cleaner, easier) to pass objects instead of properties. Even better to have an object method responsible for getting the value of a property, so that your code never accesses the property directly, but requests the value from a GetValue method (for example).

>I was instructed to carefully clean-up by saying loParentForm = NULL
>(I am guessing that is the reasoning for immediately assigning NULL
>to an object after you are finished with it). Am I correct? Is this
>NULLing of objects the bottom line to fixing C5 errors in VFP6 apps?

Well, nulling objects you've assigned during runtime to custom properties is important to release any outstanding object references that might keep a form from closing.

For example, if a form has a custom property called oRef, that is intialized to some other object during runtime (for easy access), then I must assign .NULL. to oRef when the form is destroyed. Otherwise there will be an outstanding reference to that object, and my form won't close.