COM

COM Server Types: In-Process vs. Local vs. Remote

There are three basic types of COM servers: in-process, local, and remote. What do they have in common? What are the differences? Let's explore.

Mike Wolfe

Dec 27, 2021 • 4 min read

If you are not sure what COM itself is, I recommend you start by reading my High Level Overview of COM.

COM Client vs. COM Server

What is a COM Server?

Please don't get hung up on the word "server."

A COM server is nothing more than code that exposes its functionality to external programs through the use of a standard interface. This code (the COM server) can take the form of a shared library (.dll), a custom form control (.ocx), or a standalone application (.exe).

The term "COM server" does NOT refer to a physical device.

What is a COM Client?

A COM client is the code that calls into a COM server.

A COM client can be a compiled application, a script, or VBA code. Since the focus of this blog is Microsoft Access development, all you really need to know is that your Access front-end application plays the role of COM client in all of the following scenarios.

Types of COM Servers

There are three basic types of COM servers: in-process, local, and remote.

In-Process Server

An in-process server is a COM server that gets loaded into the running Access application process (msaccess.exe).

This is the most tightly integrated type of COM server.

It uses your application's available memory.
It does not show up in Task Manager.

These are typically code libraries (e.g., .dll files) or ActiveX controls (.ocx files).

Local Server

A local COM server is an application that runs under its own Process ID (i.e., not part of the COM client application). By far, the most common examples of local COM servers in the Access world are the other Office applications:

Microsoft Excel
Microsoft Outlook
Microsoft Word
Microsoft PowerPoint

These standalone processes:

Appear in Task Manager.
Use their own memory allotment.

These are typically .exe files.

Remote Server

These are processes that are running on a different device.

Calling code on remote servers falls under the category of DCOM (distributed component object model). DCOM uses remote procedure calls (RPC) to make the process of interacting with code on a different physical device as painless as possible.

I have never personally used this approach. I don't believe it is commonly used in the Microsoft Access world, but I would love to be proven wrong. If you use DCOM to run code on remote devices from VBA in Microsoft Access, please let me know in the comments below.

Caveats

I wanted to highlight the following point that Ben Clothier makes in the comments below, as this is something that has indeed tripped me up in the past:

[I]t is true that VBA code is a COM client. However, it's actually more narrow than that because VBA & VBScript & (formerly?) JScript builds on top of OLE Automation which builds on top of COM. The COM ecosystem is much more large and encompass far more of the Windows than what is covered under OLE Automation. That is worth mentioning because though there many many COM components out there, a majority of them is not suitable for use with VBA or VBScript and cannot be used directly. That would explain why you might find a library here or there that says it has COM stuff but turns out that it can't be used in VBA because it's not Automation-compatible.

Final Note: This article is intentionally light on technical COM details. Feel free to ask questions or provide additional technical context in the comments below. While my goal was to keep this topic simple and easy for newcomers to understand, please let me know if anything in the above article is flat out wrong.

Also, let me know what other important differences exist between in-process and local COM servers. I'll update the article based on your feedback below. Thanks!