By default, under your set up scenario, the Connection Manager is running on both the workstation and the server.  Best practise is to run the default setups for workstation and server and leave it alone.

Under what circumstances do you think it would be wise to disable the Connection Manager on the workstation?

If you don't run it on the workstation, you cannot open a file on the workstation (eg. the sample file for testing, a copy of your live file for testing, conversion to new versions when you don't want to run it across the network, etc.).

Thanks for the reply Richard.  The circumstance that you identified is exactly what I would want to prevent if that was needed.  I would not want people to be able to create local files in a network environment.  In this case, that was not my intent of the question.  

With a "connection manager" software running on both the workstation and the server (Since the server should be responsible for managing connections in a client server scenario), it was just not clear to me from my searching of documentation whether there would be conflicts or if any other issues would pop up(Performance or otherwise). 

In this case, on my server, I only ran the server install so I do not have a full copy of Sage on the server and that makes sense to me.  I just have to make sure about updating as necessary.

Your answer clarified everything for me, and now I know it really doesn't matter, unless I want local file creation capabilities.

Your other points of file conversion, etc are noted as well.  

Thanks for the insight.

Terry

I've never really tried to prevent people from using local files.  By default, the sample Universal Construction file is installed locally.  However, I have stopped the local Connection Manager from running to do some testing, though I have never left it that way.  For permanence, you would have to do something at the Windows services level.

If you disable the local Connection Manager, you will not be able to test anything locally, including whether the program is being blocked by firewalls vs. an update did not install correctly, etc.

The only easy way to lock it down so no local work can be done would be to only install the full version on the server and nothing on the workstation, then setup RDP sessions for all users.  If they email, then their email will have to be set up properly, if they use spreadsheet exports, then a program like Excel would have to be available, etc.  This is not unheard of, but it might be more trouble if it is only for the one program.

Thanks, and truly, blocking local access was just hypothetical.  The core of my question was having the connection manager running on both client and server and whether it would cause conflicts, etc since I couldn't find any documentation which discussed that in any detail.  I believe that has been answered.

Terry

Terry-Bennett said:

I would not want people to be able to create local files in a network environment.

Some maintenance tasks automatically create a local workstation file, or use the local workstation MySQL engine and Connection Manager:

Backups

Year end (automatic backups)

database maintenance - Advanced Database Check (automatic backup)

For users that will never do those things, I can't see any harm in turning off or disabling those components. 

A copy or restored backup could be used to commit a fraud, however a memory stick and another workstation could, as well.

About once every couple of months I've had Sage 50 (2017.2 Quantum) attach to a local workstation database *and* a server database at the same time.

In the File | 'properties' menu it showed that it was connected to the server.  The workstation Connection Manager showed *something* connected locally, to a test file I had used the day before.  Reports and searches were showing the local data but entries went onto the server.  The Sage support guy who remote connected in said he had seen it happen before, didn't seem interested in finding out why, and was mostly eager to reboot the workstation to 'fix' the problem and 'close the ticket'. 

Shutting down the Connection Manager prevents that from happening - not that it should ever happen anyway.

Sorry, I didn't quite get that.  No conflicts between the two or up to 41 possible connection managers on a network.  They all play nice together.

There is probably no documentation that discusses it because it is the standard and intended setup by design.

Thank you for the input Randy.  Noted.

And just to clarify,  "Not wanting people to be able to create local files",   I was thinking more in general terms of people accidentally or inadvertently creating local copies of company files and working on those, thinking they are working on the live (Networked) version.  

The case you mentioned about the dual connections or "attach to a local workstation database *and* a server database at the same time.", are exactly the conflicts I was wondering if would happen and the consequences of that.

Terry