>I know that Rick Strahl (sp?) would probably disagree with me, but he is one who is ready, willing and able to get into the bowels of the OS and multiple components to achieve what is needed.
>I am referring to all of the "HYPE" about how simple and easy and quick it is to accomplish these things using straight-up OLE and VFP OLE Automation Server.

Well, not quite :-} I never claimed that it's easy. But I can tell you that most
pf the issues we deal with in VFP also apply to VB, Delphi etc. It's a different
mindset altogether and VFP has just joined the club on the first step up...

I'll say that it's simple to build an Automation server. It is and even using
the technology is easy. However, building it right is not, because you have to
know how the scalability issues work. But the fact is that
today all tools fall into this category. Building scalable application servers
is a difficult task even if you do have true multi-threaded support (try doing it
in C++ where you have to take care of all the internal serialization access to
objects).

My guess is that VFP will gain Apartment model threading in the next rev to
match what VB can do, but even with this you still have to write code to
properly load balance the servers. It's never easy...

If you need multiple server for potentially long requests single instancing
solves that problem nicely. Multi-threading without a threading model to
go with it.

>The recent (August) FoxPro Advisor mag had an article on OLE Automation, *BUT* that article was limited to making a VFP functionality available to some external application with very little effort.
>That of course is decidedly *NOT* 3-tier application design/processing!

True, but it does verify the claim that it's not difficult to implement the
feature. You do gain the functionality without making any code changes - one
switch basically does the trick. Not everyone needs to build a full scale
server.

>
>In simple terms the big problem I have come across is that, AS I READ THINGS, *ALL INVOKATIONS ARE SERIALIZED*. That is, any Client's request *MUST* completely finish before another Client's request will be processed. Who can say what this would mean to Client response on any reasonable number of terminals, even with only "average" I/O and processing requirements????
>It also appears to be a limitation of VFP at least that arrays *cannot* be passed back and forth to/from an OLE Automation Server.

Both true, and major shortcomings of VFP. In addition, VFP cannot access a number of collection
objects that are common with servers that are meant to work with VB, because VFP's array
implementation differs from VB. Next months (October) issue of FoxPro Advisor will have
an article on Active Server Pages and using Automation objects with it. I discuss the
problems in detail there.

>I have decided to wait until it can be done straightforwardly in VFP.

Don't hold your breath. VFP will most likely never be multi-threaded.
It's going to take middleware to do this. Microsoft Transaction Server
will provide some of the scalability you're looking for, but not in this
release of VFP. Apartment model threading is required to take advantage
of MTS.

+++ Rick ---