If each user has full SMB rights including modify, to the target folder on the server, and

The database engine can't communicate with the workstation using TCP/IP,

I would say try turning off / temporarily uninstalling the workstation firewall and antimalware as a test, then configuration if that's the problem.

(and possibly restart the server)

The connection works when I run as the domain administrator. No workstation firewalls are enabled and the AV software is active with the domain administrator as with any other user.

The error suggests reviewing the log files, but i'm not sure which log files they are talking about.. eventvwr?

The log files are in ghe company.SAJ folder.  i.e. if the company 'file' is MyCompany.SAI, the folder is MyCompany.SAJ.

It's significant that it works when you are the domain administrator.  As you say, you've pretty well eliminated the firewall or any local rights, as an issue.

Has the server has been restarted? (to eliminate a possible difference in what rights the Services start with on boot, vs. after installation without reboot, make sure there's no files held open that shouldn't be, etc.)  

Seriously, has the server been restarted?

The process goes more or less like this:

- Workstation client opens MyCompany.SAI using an SMB file connection.

- Workstation client figures out server name from the file connection info, and attempts to make a TCP/IP connection to the Connection Manager on port 13531

- Connection Manager verifies that it is a valid Sage 50 Client makiing the connection, and

- starts the MySQL database engine, which

- opens the 'real' data files in the .SAJ folder..

- Connection Information for the server database daemon's TCP/IP port is passed to the Client (the first one is usually 13540, second is 13541, etc.)  

So... the process is going wrong about where the database engine is opening the file.  If the database engine reported an error, then the communication all the way up to the database is working.   If the only user account that can start the database server is the domain admin, then it might not be starting as a system process?

Hey Randy,

Thanks for the heads up. No I have not restarted the server, just the db server service a few times. I have tried changing the account that the service is started under to the DA vs local service to no avail.

I'll schedule a reboot and see if that helps. I'll update here afterwards, it probably wont happen until monday morning, however.

Hey Randy,

Thanks for the heads up. No I have not restarted the server, just the db server service a few times. I have tried changing the account that the service is started under to the DA vs local service to no avail.

I'll schedule a reboot and see if that helps. I'll update here afterwards, it probably wont happen until monday morning, however.

Alrighty, so I scheduled a reboot over last weekend and was able to test out access on wednesday, and it worked.. So, reboot appears to have resolved the issue.

It's surprising how often that works!

Heh, well I spoke too soon.. it appears to work for the domain administrator account but not  the regular user accounts. I was testing with an account that was in DA as well.  so back to the drawing board. This is quite irritating as i've never had this issue with the simply accounting database manager, makes me think i'm using quickbooks insofar as it doesn't work

Sounds like you may have a Windows security issue.  What is the exact path to the files on the server?  Sometimes burying them in My Documents and then sharing that folder causes problems.  I always create my own folder off the C: or D: drive on the server, put the data files in it and share it as drive S: on each computer (if it's not already used), so everyone uses the same drive letter.  Did you try anything in the knowledgebase?

Alright. It works through a UNC path, but not through a mapped drive.

Alright. Figured it out - These shares were being mapped via DFS namespace. upon discovering that the UNC path worked I started questioning the drive mapping so I checked out the GPO that was mapping the drive. Lo and behold, it was mapped via DFS.

I modified the GPO mapping to map directly to the share, not via DFS (it's useless in this situation since there's only one server anyway)

DFS for the loss.

Sounds like it wasn't resolving the server's computer name properly.  Glad you got it sorted out.

On the contrary, the issue was DFS, not servername resolution.

If you are not familiar with DFS it's used to host file shares across multiple servers for a high availability and distributed solution. for HA you have two servers in one site, and for distributed you would have one server in two(or more) sites. You cannot access databases in the manner that sage50 accesses them using this system...or dare I say it, any databases using any database engine.