cursoradapters by default sharing/getting a connection via form which gets it via app, so at each level another connection might be introduced like a second server if the data layout calls for it

>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??
>>>
>>>
>>>.