Hi Charlie,

I've just implemented your idea. Now I'm testing...

Thanks.

>PMFJI,
>Hi Vlad,
>Your suggestion of using another form is the idea I have, only I just don't use a form. You already know that if you have several forms you can talk to them without concern about their datasessions. Form1.Refresh() and Form2.Refresh() just work. Nothing loses track of it's stuff. It's the same with a Session object IF you forget about switching DataSession IDs and just create what you want IN the methods of the Session Object. Don't create the session object and then switch to its newly created DataSession. Call a method in the object to do what you want. SET DATASESSION TO is only for debugging, IMO, not for use in an application.
>
>>Hi!
>>
>>>>But really weird results could be expected when making something like Nadya. I forget about Session object at all so far because it takes much more time for "tuning" of such approaches compare too other work-around approaches without use of session object at all. I did not found any reasons to use session object so far.
>>>
>>>There's really nothing bad or unreliable about Private Datasessions and calling other objects, you just have to be aware of what's going on when you use them.
>>>
>>
>>Agree. But how much of time requires 'tuning' of such approaches? Much more than time required to develop much more reliable workaround. Messing with dependencies between different objects and their data sessions takes some time...