Manny

I had this problem yesterday. It was a firewall issue on the server in my case. If you change the server firewall to allow all inbound connections it should work.

If so, then set it back to Block to only allow programs through that meet the rules, then add some Inbound Rules to allow the following (you may not need all of them but I didn't have time test each one individually. It was payroll day.

C:\Program Files (x86)\winsim\ConnectionManager\Simply.SystemTrayIcon.exe
C:\Program Files (x86)\winsim\ConnectionManager\SimplyConnectionManager.exe
C:\Program Files (x86)\winsim\ConnectionManager\MySqlBinary\5.6.10\MySQL\MySQL.exe
C:\Program Files (x86)\winsim\ConnectionManager\MySqlBinary\5.6.10\MySQL\mysqld.exe
C:\Program Files (x86)\winsim\ConnectionManager\MySqlBinary\5.6.10\MySQL\mysqladmin.exe
C:\Program Files (x86)\winsim\ConnectionManager\MySqlBinary\5.6.10\MySQL\mysqldump.exe

You should be ok with setting them up on Private unless you are using the Domain features, the I would use Domain.

Hope this helps

Edit:

Sorry pulled the paths off my desktop, I assume 64 bit computer so you want the (x86) folder.

That didn't work. In fact I have tried turning off the firewalls completely on the workstation and the server with the same result.
Yet it still works fine when logging into the local work station and mapping a drive to the data on the server.

What is the absolute path to the files on the server. The IT guy at my clients had shared the Administrator\My Documents folder on the server and everyone was trying to access from there.

I created a c:\Sage50Data folder and shared it for only the users needing it. With all those changes the files opened up without any problems.

The data is stored in Server folder files specifically created for all the sage data (multiple folders for different company files)
It is not a matter of being able to open the files because as I have mentioned it works fine if you do not log into the domain.

Not sure what else to suggest.  If you have added those programs I mentioned to the inbound rules for private and/or domain and you can see the files, create a text document and edit it in the data folder from the work station, then the only other thing I can think of that you might need to do is open ports 13531, 13540 and 13541 to see if that will help.

If you can't create, edit and save a text document in the data location then you may have a network permissions issue but I've ignored that possibility to this point because it sounds like the network communication itself was ok.

You can also try accessing the files on the server via IP or UNC address instead of mapped network drive to see if that helps.  On some systems that does seem to be necessary. 

This is a list of the full set of programs Sage has indicated should be allowed through the firewall.  I've never needed to add them all.  If you search the Knowledgebase for "firewall" you will see more articles that may help.

Any time the Knowledgebase mentions the path to the MySQLBinary\5.0.38 replace it with 5.6.10.  Same with mysqld-nt.exe = mysqld.exe for the 2016 version.

Manny Singer said:

I have mentioned it works fine if you do not log into the domain.

If you log in with different rights, one way it works and one way it doesn't, it's a rights issue at the server.  The server is allowing different access to different user accounts, which causes the connection attempts to work differently.  

Are the services (Sage 50 connection Manager, MySQL Daemon) running as the user recommended by Sage?  It may be necessary to restart the server after any installation or configuration change, in order to start the services with the appropriate security access. 

Manny Singer said:

It is not a matter of being able to open the files

The SMB connection to the company .SAI file is just the first step. 

The client then attempts to connect to the Connection Manager using TCP/IP, usually on Port 13531.

The Connection Manager then starts the MySQL Database and gives it the company database folder location and the next available port to listen on. 

If that works, the Connection Manager passes the database port number back to the client at the workstation.

The error message "Connection manager can not start the database engine" is literal.   The client asked for the data, but the Connection Manager on the server was either not allowed to start the Database engine by Windows Server security, or something is broken. 

Good point Randy. Manny check on the server to see if the Connection Manager is properly running. You will find it in the systray, click on it and look at the top right to see if it is is running and it is running as a system service - both should say Yes.

Also make sure it is version 5.2 at the top right. If not, the problem is that the server was not updated with the proper connection manager when 2016.2 was installed on the local workstations.

Hi All,

I solved the problem myself by actually mapping a drive to the data folder on the server (same as I was doing when I was not connected to the server domain login).

All of the other replies that you all sent me were already done and still didn't work.

Why this happens is still a mystery since using the shared server folder should have the same permissions as mapping directly to it.

Anyway thanks for your help,

Manny

Sorry, I just assumed you would be using a mapped drive instead of using the UNC path. That's why I mentioned trying the IP address or UNC instead. I always use drive S: for Sage 50 when I have the choice. Glad you have it figured out.