>>>>>I need to pass a cursor that resides in a form with data session set to private to another form. I know it kind of defeats the whole purpose of having a DS that's private and wanting to do this but I have the need nonetheless. I know I can't pass a whole cursor as a parameter (w/o using ADO?) but is there another way?
>>>>
>>>>Sure - pass the data session ID and alias as parameters, and do something like:
>>>>
>>>>LPARAMETERS nDataSessionID, cAlias
>>>>* Note - no error checking. I'd add it.
>>>>LOCAL nMyDataSessionAtStart
>>>>nMyDataSessionAtStart = SET('DATASESSION')
>>>>SET DATASESSION TO nDataSessionID
>>>>LOCAL cDBFReference
>>>>cDBFReference = DBF(cAlias)
>>>>SET DATASESSION TO nMyDataSessionAtStart
>>>>USE (cDBFReference) AGAIN SHARED IN 0 ALIAS WhatEver
>>>Wouldn't this cause problems if we have some data bound controls ???
>>
>>Not unless one of the sessions needed exclusive use of the cursor; you can open a table or cursor several times without difficulties. The record pointers move independently of each other, so it won't cause a form with another 'use' of the cursor to shft records unexpectedly. This is no different than having two datasessions open the same table...
>
>
>I don't mean having problems with the cursor that is passed. When we have some data bound controls on a form on different sources maybe, then when the form changes datasession it seems the controls loose their data source which "reside" in the old data session ... Have you test your solution with data bound controls?. If I am wrong it is really very usefull !

I use this all the time; it passes the the data session id and alias as a reference point; once you have that, you can find the underlying table, and open it again. If you need to position to the same record, you can grab RECNO() at the same time that you grab the name of the table and position to it.

This will not coordinate movement of the record pointer between the two sessions if that is your concern. The original data session remains positioned on the same record, and the second session is free to make whatever changes it likes, moving around in the table, making changes, etc. It's necessary to do a requery and refresh in the original session to get changes to the table to appear in the original cursor; that can be handled in the orignating form's GotFocus event. This hasn't been an issue where I've used this approach in the past, since the framework I use normally handles requeries on form switches. If you needed to reposition in the first form, that would require a separate effort to pass the new record position in the table to the orignal form when shifting back, and then the form would move the record pointer in the originating data session after the requery and before refreshing the data-bound controls on the original form. It would be messy, and if I had to do it, I'd probably try coordination through some sort of a Voyeur-pattern class which would track the record position and realigned/requeried in all data sessions using the shared and synced table. Before asking, I don't have such a beastie pre-rolled, but someone else might.