Ahhh...there is a problem with accurately determining the datasession ID of a private datasession (althought the details escape me). Try connecting to your database in the default datasession before opening your form. The form will still have access to the cursor (as will the rest of your app which appears to be a goal).

>Yes, the form is using a Private datasession, however, I send in the DataSessionID and Set the DatasessionID in the stored proc to the current private data session. I have determined that it has something to do with the command SET DATASESSION TO.
>
>>Is the form using a Private datasession? Maybe you should look at using the new Session class to handle interaction with the server DB and/or create a public Custom object that handles that.
>>
>>>Thank you John for the quick response, I am using SQLSTRINGCONNECT, however, I don't want to fire SQLDISCONNECT, because it will be used other places in the Application; and, yes, I do close the cursor I create with the stored procedure.
>>>
>>>
>>>>Hi Monte,
>>>>
>>>>If you're calling an sp, you must be using SQLCONNECT...are you cleaning things up with SQLDISCONNECT? And are you explicitly closing the cursor returned from the SP? VFP won't do that automatically.
>>>>
>>>>
>>>>>I have a form that calls a SQL Server stored procedure that returns a view. The form runs fine, however, after the form is closed, it leaves what I call a hanging datasession open. After, I run the form and the stored procedure fires, I close the form...and it closes O.K., but, the Data Session window shows that a data session still exists it reads "Current Session: Unknown(2)" Does anyone know what's going on here?
>>>>>
>>>>>Thank you,
>>>>>
>>>>>MOnTe