Ed,

You have far more *real* experience at this than I do, and I appreciate your taking the time that you did here.

Stating it bluntly. . . while VFP may be being *aimed* at the middle tier, this is by far still more bluster than fact and there is quite some way to go yet before it can be deployed that way.

In the meantime this "objective" relieves the VFP team of improving the tier-1 features and facilities, be it directly in the language *or* in ActiveX.

What we end up with at this point is a product which reputedly (in print and at sessions and as generally publicized) does middle-tier but in fact offers a *VERY* limited rendition of it, and is basically frozen as far as language enhancement and ActiveX support is concerned.

Yet virtually no one want to challenge this with MS and *try* to bring about change!

It was even reported that Bill Gates himself, at the last TechEd keynote (I believe) stated that one thing MS has learned is that they have to get closer to their user base. Well, if that is true, and the VFP team so small, the VFP team ought to have been right out there immediately carrying out that "philosophy" under the guise of Mr. Gates' 'directive'. But has anyone seen any evidence of this?

I originally said that I didn't much care if VFP was aimed at middle-tier provided that they continued to develop the language. I stick by that, but acknowledge that they are not doing either at this point.

Cheers,

Jim N

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