Yes we'd be calling from different asp pages. I think I could differentiate between them simply by being careful with the names of the function calls. Such as:

oServer.LoginSite1()
vs
oServer.LoginSite2()

The only issue is the server gets bigger and more complex if it is serving 2 sites instead of just 1. Also, the first site which is already up and running will be impacted while I do any debugging on the second site. So, I'd prefer to not mess with the existing dll if I don't have to.

:) - Don

>If your calling from different sets of ASP pages, is there some automatic identifier you could use as a parameter... ie: if the pages are from
>
>YourServer.com/ClientA/SomePage.asp
>vs
>YourServer.com/ClientB/SomePage.asp
>
>where you could identify the origin path (client a vs b) for example. Then when you call the com, pass the request object and search the the url path that invoked the call. Then, internally to the DLL, show respective data.
>
>
>
>
>>Thanks Don -
>>My first dll server is compiled as a multi-use item and has been running without a problem for a couple of years now. What I'm talking about is ceateing a second dll on the same domain (same box) that will provide different functionality for a different set of users. What is unclear to me is whether this is possible (or advisable) or whether the additional functions should be added to the existing dll COM object.
>>
>>- Don
>>
>>>It may mean only one instance of the COM object, but based on how you COMPILE THE PROJECT, you can specify a single or multi-threaded server.
>>>
>>>If you modify the project, right-click, then project-info. Look at the "Servers" tab. It will show the recognized OLE-PUBLIC classes... Look to the right for "Instancing" for Single-Use vs Multi-Use. Set to multi-use. Maybe that helps clarify what you are looking for.
>>>
>>>
>>>
>>>>Rick Strahl's paper on building web applications with Visual FoxPro states
>>>that:
>>>>
>>>>"Active Server wants to work with DLL based Automation objects, but Visual FoxPro will allow you to only use ONE DLL based server per web server as VFP only supports a single copy of the runtime in memory of any single process (in this case the Web server)."
>>>>
>>>>I am trying to understand this statement. Does this mean that if I have a DLL based COM object residing on the server to serve up data for a particular set of asp pages, that I cannot add a second DLL based COM object (in a second DLL) to serve up data for a different set of asp pages?
>>>>
>>>>If this is true I suppose I could build the additional functionality into the first COM but this would essentially put 2 websites into the same DLL which will complicate things a bit.
>>>>
>>>>Can anyone tell me if this is a correct analysis?
>>>>
>>>>Thanks