>>Thanks Larry
>>
>>I can think of a few places in my app where that technique will be useful:)
>>
>>What are your feelings about using SET DATASESSION in general.
>>
>>The help topic for it says.
>>
>>SET DATASESSION is typically used to debug forms, and should not be issued when a form is active.
>>
>>I am hoping that this is wrong and that I can use it with caution.
>>
>
>The only place I use SET DATASESSION is the Load method of a form. If you use it any other place, you are asking for trouble.
>
>The reason being is that in any other method of a form, the Controls have already been instantiated and if data entyr controls, been bound to the underlying data source. If the data source is a field in a cursor then changing datasessions will break that link and your form will blank out on the next refresh. This is especially true when using a grid. The grid will basically self-destruct if this happens.
>
>I have used SET DATASESSION in the Load method of forms that were configured as participating in the Default Datasession (1) and not 2. AT that time, I used a form manager that exists in datassession #1. Because the form manager actually ran the form, the form was launched in datasession #1. I added code to the Load method to check for the existence of _Screen.ActiveForm and if it existed, then I set the datasession to the datasessionID of the active form.
>
>The assumption was the new form was supposed to particpiate in the datasession of the current form not the datasession of the form manager.
>
>HTH.

That's exactly the way I use SET DATASESSION TO. Another place I've had to use it is when I have a application type object that needs to reference tables from a PRIVATE DATASESSION type form. The application object has to do a SET DATASESSION TO the form's datasession, do it's manipulation, and then SET DATASESSION back to the original one of the application object.