The need here is for a single app-level Sql Server connection object that is shared by all forms, otherwise, the app will wind up with many separate hard connections to the Sql Server, which is not good.

So, while I agree with the general principle of your suggestion, I believe this case calls for a solution that allows one master connection object to serve all queries, while being sure that the resulting cursors wind up in the Private DataSession of the calling form.

There are indeed several ways to handle this scenario. I found a solution that I like and that fits well with existing code patterns in my app and data access framework. Which is not to say that other suggestions here are wrong or unacceptable. I was just curious to hear how others had dealt with similar matters.


>Hi Matt
>
>If form B is really contributing to the workflow of form A, have form B adopt the datasession of Form A. If Form B is truly separate from the workflow of form A, then Form B really should not be interacting with classes of Form A at all. It would be like my lending you my heart, while I'm still connected to it.
>
>>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??
>>
>>
>>.