Hi Fred,
The "coding" you mention is a result of mixing OOP and old practices. Using private data sessions is the way to go to let each form stand on its own. I use a class does all the data stuff for each form--call it a data class or business object--it's all the same thing. I "knows" which record to default to.
Form A can park on a customer record. It sends a message to the Application object saying 'I parked on record "3RT" of the customer file.' Form B or any other interested party can ask the Application object who the default customer should be and it will respond "3RT". During testing, there doesn't to be an Application object and the form will work, however, it won't always start with the desired record--you may have to navigate.
When you use a default datasession for several forms, you are using the tables/cursors to communication from form to form. That's OK, but as with your example problem, it's not always easy to control all the additional baggage of relations, orders, aliases, and pointers.

Glad the SET RELATION worked out.

>Hi Charlie,
>
>Thanks for the tip. In my FoxPro 2.6 days, I never save the environment with the screens, I always controlled everything
>from the program. I was hoping that I could get away from that with VFP, but I guess there are still going to be
>instances where coding will still be needed.
>
>I am experimenting with your suggestion now. Thanks.
>
>Fred

Charlie