>>>>Here's what I'm finding...
>>>>
>>>>Any object in FoxPro that runs a query, whether against native DBFs or Sql Server, will create the cursor in the DataSession which was active at the time the object was created.
>>>>
>>>>The means that if you have a BO created in Form A with a Private DataSession, and you pass that object to Form B which has its own Private DataSession, if you use the object to run a query from Form B, the cursor will be created in the DataSession from Form A.
>>>>
>>>>Crazy! But true. It took be about an hour of stepping through the codez to figure this out.
>>>>
>>>>Does anyone know a work around, or a pattern to avoid this??
>>>>
>>>>
>>>>.
>>>
>>>Did you expect it to work differently? If your object opened some tables when Form A was executing, and then you passed that object to Form B, don't you expect those tables to be still open and available? That would only be true if it still was in the same DataSession as Form A.
>>
>>
>>My gripe with this is not the handling or access of existing cursors created with the object... It's with new cursors created with that object in Form B, or Form C, etc.. I'd think it would be reasonable to expect the results from a new query run in Form X to be created in the DataSession of Form X. That's not an absurd use case. There is no concrete right or wrong way to say how this should work. VFP chose to make it work the way it does, which is not what I need in this case, so I'm seeking reasonable work-arounds to accomplish what I need.
>>
>>The VFP architects could have simply added a property on Custom objects that determine "shall the results of new queries created with this object be created in the current DataSession, or the original Data Session which was active when the object was created." That would be most useful to me at this time.
>>
>>
>
>So then you would expect that an object could open tables or create cursors (when invoked by Form A) which would not be available when the same object was called by Form B? That the Data Session for this object would change underfoot, as it were, and the object would not know about it?
>
>You claim that there is no concrete right/wrong, but I would think that having an object that had no knowledge or control of its datasession from one use to another could be terribly hard to work with.


>> terribly hard to work with.


Of course, that's where my suggested "shall the results of new queries created with this object be created in the current DataSession, or the original Data Session which was active when the object was created" property would be so helpful. We'd have full control of either way, and with subclassing and all that fancy stuff, I'm sure the skilled VFP folks could figure out how to take advantage of this.

I bet VFP 10 will have this feature when it comes out in the Fall.

.