Mark, >While it is good of you to "defend" MS on this issue, their current tack, at least for VFP, causes more problems than providing solutions! I could concievably have dived into creating an OLE Application Server using VFP, only to find out THE ONLY WAY POSSIBLE (from the info provided with VFP and in the more common "public" areas of MS) that the thing simply cannot handle any volume of Clients! I truly feel it is my background in mainframe performance issues which gave me the sense to ask some pointed questions before I got going. Somehow I think that the 'average' PC person might just have gotten suckered in. At the very least there ought to have been a statement regarding single execution (queued requests) and performance implications. Again, it depends on how you read the docs. While it says nowhere that VFP is single threaded it's something that you should always test for immediately with any product when you start building any type of 'server' application. VB4 did the same thing and the docs never stated the fact. Same thing with Delphi 2 etc. IOW, there's nothing unusual about this. VB5 supports limited multi-threading via Apartment model threading and Delphi 3 supports full COM support for true free threaded servers. I would suspect the next rev of VFP will match VB's capabilities, but of course we won't know until the time comes. For now the pool manager approach or not using Automation will let you do what you need and do it well. VFP backends are definitely capable - one loook at this site which I've been told is getting 250,000 VFP hits a day should tell you the story. On another Automation isn't the only route to go. You can do what you need using Automation in either FoxISAPI or Web Connection. However, Web Connection (WC works both with Automation and file based messaging), x-Works and FoxWeb all work without Automation running multiple FoxPro sessions to provide a simulation of multi-threading. While this sounds resource intensive it really isn't as long as your box has enough memory. Memory is cheap and that's what servers are for to house huge hardware... You have to keep in mind that all this Web stuff is setting the dev landscape upside down. Look at what's been accomplished in less than a year - you can now build apps that simply wouldn't have been possible 2 years ago! Most people including myself weren't/aren't ready to change their mindset from application programming to server programming. It takes a different approach to build apps and a different set of pre-requisites to do it right. Web development really requires understanding of networks, a little of how the system (NT in this case) works. I'm not happy about seeing flashy demos by MS and other vendors that aim to tell developers this is easy - you can do it with your eyes closed. Sure, simple stuff on light volume traffic, but as soon as load goes up you need to understand were the bottlenecks are both in your code and in the system. Ain't no such thing as a free lunch... +++ Rick ---