>>PMJI. I think again it's an issue of how you return data from a VFP middle tier to a client. You can't return a VFP cursor, but you can return an ADO recordset. Also, if you're using MTS VB has much better support than VFP 5.0 and, from what I understand, better support than VFP 6.0.
>
>Hey Josh,
> In the middle tier you can use all of Fox's native data manipulation then convert your result to ADO (via Ken Levy's class?) and return it. Unless you are return thousands of rows (which in c/s you shouldn't be) I don't think it will be a great performance hit.
> Also - what leads you to beleive that VFP 6.0 MTS support is not as good as VB?

True, it may be more efficient to use VFP to manipulate the data then convert it to an ADO recordset. I think it depends on how complex the manipulation you need to do after you get the data from the server is. If you're just doing a query then passing the results to the client, all ADO may be more efficient.

As far as VFP 6.0's problem with MTS support, it's the concurrency issue that we first heard about from Rick Strahl at DevCon. I asked Randy Brown about it and he said, "Well, yeah, if two clients try to access the same method of an object one will be blocked until the other's request is completed." He seemed pretty unconcerned with this which amazed me. Microsoft's solution seems to be to run your objects in multiple MTS packages and write a pool manager to allocate the resources among your different packages. This sounds a lot like working without MTS.