-snip- (with apologies to any who need the details)

>Note, though, that the discussion revolves around VFP, so the fact that a C++ OUT-PROCESS server *can* handle multiple simultaneous clients is *NOT* material to this discussion. In fact, it is the general clouding of this very issue by many many writers that prompted me to say what I originally did - to "warn" anybody who may care that when people talk of being able to do most whatever one wants, that certainly is *NOT* the case for VFP despite what they may read.
>

Jim,

One of the great problems that I see with VFP in the mid-tier role is scalability. VFP 5.0, and from what I understand, 6.0 at initial release, does not scale via MTS well; the thread model isn't there, it's inherently a single client service instance, it's stateful, and each instance requires the entire runtime to load. VFP servers running in a common process also do not seem to be reentrant, blithely smashing each other's sessions.

I deal with things from the other end of the world; I develop COM and DCOM objects that are being integrated into VFP apps now, and I'm constantly fighting the mid-tier battle. Two of our components are pretty much mid-tier services, one that determines how long it'll take to get a shipment from point A to point B, the other shipping rules and rates. Both are fairly data intensive, but the data is read-only while the COM object is active. We tried implementing both in VFP, and VFP simply won't cut it. And these really are classic mid-tier business rule services, where we made an active decision not to have our rules servers own the transaction log, and have data-driven objects to model the business environment.

VFP, aside from the issues with ActiveX and the pain we go through to make full use of the WinAPIs, has been a good front-end for us, and a great data analysis and data generation tool (we use it for data conversion, to maintain and generate the rules data for our COM objects, do ad-hoc analysis of collected data, and script some of our installation processes.) Unfortunately, from what I see, M$ isn't making the changes needed to improve VFP as a front-end tool, at least from the standpoint of ActiveX component support and thin-client deployment, and while they talk a good game at the mid-tier level, haven't made the changes necessary to scale and deploy via MTS yet (yeah, I know, RSN, but how often have we heard that about changes to VFP?) And it isn't SQL Server, and really never will be.

From a COM standpoint, where does that leave the VFP developer? To me, it looks like out in the cold again...

Ed