>>You can't bypass the SQL server license model just by moving a COM component to a common machine. 10 users accessing a database is still 10 users accessing a database. If the serveer is out of proc, or hosted in a MTS package, you can use DCOMCNFG to change the account that the server will impersonate while it operates, but I don't think that this helps the instance/connection situation.
>
>This app is built on a VFP database and updates to SQL Server only when a save is done. (I can explain why I am using this model if you like.) Rather than having each user having a connection to SQL Server (or opening and closing connections to do saves) I wanted to send all requests to update SQL Server to a COM on the server that would maintain one open connection to SQL Server.

This is why you're running into this issue. AFAIK, you can't do that, because DCOM doesn't work that way. Like I said in my previous post, the physical location of the component doing the updating has nothing to do with the licensing model. If multiple users are accessing the database, you need multiple connections (and multiple licenses), unless the controlling process is a web server, in which case you need a specific web server license. Even if you find a way to do what you are trying to do, you will be breaking the SQL license agreement.

>This a multi-thread out process COM. (I do not see a way to access a DLL sitting on the server, maybe I am missing something.)

Again, a dll cannot be configured to run remotely unless it runs inside an MTS package or a COM+ Application, in which case impersonation is set on the package or app, not with DCOM.

>I tried setting the COM Identity property in DCOMCNFG but that only servered to allow access only to the user set in this property.

Did you grant the group in question overall DCOM rights on the server?