>Hi Ed:
>
>>>Question: I didn't mention that each program (2 from each workstation) polls MyCom.EXE every second. Will MTS delay response back to the workstations?
>>>
>>
>>Remote access of the COM server will introduce a significant delay compared to local out-of-process access, since each call must be marshalled across the wire to the server twice - one request inbound to the remote server, and at least one reply outbound back every time a method or property is referenced, so traffic over the wire introduces delays. And then comes the issue of servicing 40 requests in parallel - an MTDLL runs on a single processor instance. In general, MTS managed objects need to be stateless - they do not rely on the server maintaining the context of itself relative to each session, so in general, more information will need to be passed for each method call to reestablish the context of a transaction.
>>
>>I doubt that the issue of MTS will be as great as the communication latency and added cost of establishing or maintaining states. What does the COM server do that makes execution on the remote server attractive?
>
>Thanks for your reply.
>
>All the COM server does is run Stored Procedures (SQL SERVER 7) and return a RecordSet or a String.
>
>I was thinking if I can run the Stored Procedures on the server itself, it'd obtain, perhaps, a quicker response to the requests. Wrong?

If the SPs are being issued to and processed by SQL Server, they're already handled at the server - all the COM server does is repackage the result to offer a different interface! If the SPs are actually VFP code run in a DBC which includes some remote views, and the VFP server resides on the same box as SQL server, then the time to move data to the VFP server is reduced, but if the VFP server is a separate system, then the view moves across the wire anyway, gets munched by the VFP server, and then gets sent over the wire again back to the remote client...so if you aren't CPU bound for the app, you reduce the bandwidth needed to service each request by keeping the VFP server local - the data moves from SQL Server to the VFP server, which crunches the data, but then only marshals data without using up LAN bandwidth, so the LAN doesn't resend the result using it's bandwidth. The less processor-intensive the VFP server is, the less it will impinge the client app's performance to run locally.

Other issues may affect the decision about where to deploy the COM server, for example, where there's significanly greater bandwidth between the SQL Server engine and the COM server than between the COM server and the COM client, but that's a general, so if the COM server can reduce the amount of data going to it's clients, it will reduce the bandwidth needed by the client instance - the client sends a request to the server over a low bandwidth connection, the COM Server sends it off to the SQL Server over a high-bandwidth connection and passes back an initial result set that the COM server squishes even more before sending it back over the low-bandwidth connection; even where the squish is relatively small, the COM server acts as a buffer between SQL Server's transport layer and the ultimate recipient - once the packet arrives at the COM server, the SQL Server system is off the hook for delivering that data.