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?


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


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.



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




Thanks in advance keeping me straight.