>Hi!
>
>Sometimes I get weird results. For example, I call from the form a method of custom object inside of another custom object (added at run-time). It called with default data session instead of form's data session, that forced us to use data session ID as parameter to methods of this class. Now call of that method looks like
>
>oApp.oServer.RunQuery(cMyQuery, "MyAlias", thisform.DataSessionID)
>

That's because ALL objects use the datasession in which they were created. This can cause you some grief if you're calling a method on an Application Object, because the AO method will use the datasession (more than likely the "default") that it was created in. It can catch you by surprise, especially if it's called from a Private Datasession.

>That "thisform.DataSessionID" parameter at the end of each call makes me ill, specially when I forget to include it... ;-((((

Sorry, but there's no help for that. If you change it, you've got to remember to clean up after yourself, that's all. It's not really different from having to remember to put the current data area back in old code if you had to change it in old procedural code from 2.6.

>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.

>>>Hi!
>>>
>>>I never even tried to work with data session by that way because I know a lot of bad things about it. Private data sessions are not reliable in VFP even when used by usual way, what say about manual editing?
>>
>>What makes you say that private data sessions are not reliable?