>Craig, thanks for taking the time on this one.
>


>Hmm...
>

>I was thinking about creating several out-of-process VFP .exe's (one for every "major action" like inserting records to SQL-Server, deleting records, etc.) and bring them up using CreateObject (VFP client) or ServerCreateObject (IIS client). But I thought that when either was called, the whole executable loads into the client's memory space; not a big deal when dealing with IIS but a very big deal with VFP desktops. Is that correct?

It will be VERY slow because the EXE will have to load into memory every time.


>

>I also thought that making them .exe's would lead to better crash protection (although the latest article in Win2k Magazine says oop-exe's make inetinfo crash more). Is that correct?

I can't comment on that, but if you run an DLL in MTS, it runs in MTS memory space. MTS has pretty good crash protection. You'll also be able to easily update the DLL without shutting down IIS.


>

>I also thought that I would, after every CreateObject, pass a string to the object saying what the client platform is and let the .exe decide what kind of data to pass back based on this "header". Does that make sense?

No, cause you'll need to maintain state in the COM object, which isn't a good idea.

>

>I definitely want to use the middle-tier (MTS) for NTLM authentication. The security is what drew me to it in the first place. The other thing that drew me to it is the promise of having the .exe's on two different remote machines and if one crashes the clients can go to the other one. But that's DCOM and I am not sure where that figures into/outof MTS.
>



MTS uses DCOM. That's how the user gets to the COM Object. You're too concerned about crashes. I've had very few crashes with my COM objects running in MTS. The client's can't just switch over to another machine because the machine name is setup as part of the DCOM call. What you want to do is part of the promise of COM+...namely the OS automatically takes care of this, but this feature is not yet available. It's supposed to be part of the Win2K Datacenter Edition, due out later this year.


>>
>>2. Then I thought I would just do an in-proc VFP .dll instead because then I could make it run inside MTS, but I am still instantiating an object inside of the client-tier's memory space. I think I also have to put some client-side logic there to talk to MTS in order to support the rollback/commit logic that the mid-tier is supposed to be doing.
>

>No, the object will be running on the server.
>

>Can you ballpark me what kind of memory is being used on the client box? Is it less if the remote MTS object is a .dll vs .exe? I can't see what any advantage a .dll has over an .exe aside from speed in the inproc-vs-outofproc context switch. And I'd just throw more CPU at it if speed is a problem.

I haven't looked into this, but the DLL should take less memory because there are several commands (UI stuff) that have been stripped out of the runtime DLLs. If you're going to MTS, you MUST make a DLL. The Multi-threaded DLL can also take advantage of multiprocessors.


>
>
>
>
>Thanks in advance keeping me straight.