>>OK Erik, here's my last shot. In the BeforeOpenTables event, issue a SET DATASESSION TO (_Screen.MyForm.DataSessionID). I guess that will mean that as long as the form is a member of _SCREEN, then you won't have to declare anything public. Don't put any tables in the report's data environment.
>>
>>NOW, you should be able to use Ed's idea.
>>
>>HTH.
>
>Matt- that's a pretty creative idea, I didn't know you could do such a thing. I still foresee problems however with multiple instances of the form. If the name of the form is hardcoded into the report, than I would have to open the form with NAME to make sure that any instances get the right name, and this would generate an error once the second form is opened. If I rely on VFP to name the forms as they are opened it will give additional instances different names to avoid a name already in use, and the report would not recognize which form to set its datasession to. I really appreciate all of your ideas, Matt, they have really helped me to brainstorm. As for now though, I think I will have to go with the alternative view without its parameter. Thanks again.
>
>Erik
>
>Erik

OK, now I sound like UPS. Here's my next last shot....

The form always has the same parentclass right? What if you had a property of the form called lReport. Set it true before issuing your REPORT FORM. Use a loop with controlcount to find the form with the correct parentclass and .lReport. Use that datasessionid.

Try THAT one on for size.

Erik, you've created a monster. I can't stop until you've solved this. :)