I guess we're still using single-threaded because single-threaded was the only choice VFP offered back when we first created the COM object. I was planning to re-compile the COM object as multi-threaded, but I didn't know if there were any drawbacks to this. It sounds like multi-threaded is the way to go.

Thanks,
Jonathan

>Just curious: whatever gave you the idea that you needed a single-threaded COM Server on the web? The biggest drawback of a single-threaded server is that it will not scale at all and, if you have more than 1 user on the web(which is very likely), they'll be waiting around for results.
>You'll be using the more streamlined runtime for a vfp mtdll, but, I really don't see any disadvantages to using it, only advantages. A vfp mtdll will scale with multiple users on the web and present a responsive web application, be it a web service or regular web app.
>Some of the early MS web service examples made a big mistake by saying to compile to a Single Threaded dll. But, if you look at all of the latest VFP9 web service examples, they're all created as VFP mtdlls. The latest versions may be a little faster, but, I've found the VFP5SP6 vfp mtdlls to be very stable...
>>We are trying to create an instance of a VFP 6 SP5 COM object from a .NET web service. It wasn't working, and I found some articles about web services being multi-threaded, and can't automatically use single-threaded COM objects. So I recompiled our COM object as a Multi-Threaded COM Server, which seems to now be creatable from our .NET web service. I also saw that there is a way to create the single-threaded COM object by using the System.Threading namespace, but I haven't tried that yet.
>>
>>My question is this: Are there any drawbacks to compiling the COM object as multi-threaded, or should I look into the System.Threading method of calling the single-threaded COM object?
>>
>>Thanks,
>>Jonathan