Absolutely you can do this. Before you return from the object, make sure you set its datasession back to the default [1]. If you do not, that object will then reside in the form's private DS. When you release the form, the DS for that form will not be destroyed and will remain as UNKNOWN. I guess this would be known as a dangling reference.

From the form, the code would be something like:

oSQLObject.SomeMethod(ThisForm.DataSessionID)

In the oSQLObject method:

lparameter tnDSID
...
local lnOldDSID
lnOldDSID = set('datasession')   && probably is DS #1 but this is better
set datasession to (tnDSID)
...
... do your stuff here
...
set datasession to (lnOldDSID)  
return

>Hi all!
>
>In VFP6's help about the SET DATASESSION command, there is this paragraph:
>
>SET DATASESSION is typically used to debug forms, and should not be issued when a form is active.
>
>However, I have this scenario: I have an object that talks to SQLServer (doing the SELECTs, INSERTs and so on). I created this object in my main prg because I want to share it for all forms - no need to have more than one connection. Forms use private datasessions, of course.
>
>However, if, from a form, I call my SQL object to do a query, it executes the query in datasession 1 (default datasession), not in the form's datasession.
>
>Is it acceptable in such a case to use the SET DATASESSION command in my SQL object so that the query will run in the form's datasession? This is what I'm currently doing and I haven't run into any problem, but does anyone ever has? Or is there a better way of doing this?
>
>Thanks!