You are on the right track, the PSQL 311x errors are network disconnects / communication disruptions between the client and the server.   Last digit can change depending on what operation the client was in (reading data, writing data, etc).  This can be a tough one to fix, but I have seen some oddball items cause this to happen.  We support SentinelOne and doubt it is a problem if you are keeping S1 up to date on server and workstations.

You are on the right track looking at the communications between the switch and the workstations.  You can create these errors by removing the ethernet connection and reconnecting it when the user is doing something in Sage 300 CRE (do it in sampel data, please).  Hopefully, you have a managed switch and can monitor the ports.  When was the last time the switch was rebooted?  Many times, those switches are on a UPS and are up for years.  Have you just tried power cycling the switch?  Are you seeing any CRC or truncated packets on any ports?  You do have the workstations and server on the same network segment, right?  No router / firewall between them?  Propagation delay will cause these errors too.

You can also check the PSQL logs at C:\ProgramData\Actian\PSQL\logs\pvsw.log.  This is just a text file, and you can review it on the server and workstations.  Server is probably clean, but you may find this is happening a lot more at the workstations than you realize.  You may also find other errors that may show up that will point you to other things to look at.

In the past year, I have seen these errors caused at 2 customers due to the backups running during the day when users are in Sage.  If the Sage server is a virtual machine (and I would hope it is), then what backup system are you using?  If it is hypervisor aware, then that could be your problem.  Those backup systems that initiate a hypervisor snapshot (like Veeam does against VMware ESX / vSphere) will cause the VM to freeze for a short period of time, say 5 to 30 seconds while the snapshot is created.  If your backup does that, that is your network disconnect.  The Sage client on the workstation is talking to the server and expecting responses in milliseconds and when the server goes to sleep for 5 seconds, that will generate a 311x at the client (not the server).  The two customers I saw this changed the backups to only run after hours and the problems went away.

A couple of other random thoughts, ensure you have Windows Fast Startup turned off on your notebooks (I assume they are all SSD).  Also set the units to not go to sleep when on A/C. These are longshots but both can be problematic, the first in general the 2^nd with Sage.

Disabling the PSQL cache that was suggested is OK, but another long shot.  Give it a go.

These 311x errors can be hard.  Been supporting Sage 300 CRE for 25+ years and every time I have had to work on it, it comes down to loss in communications.  It can take some time and effort to find, but it always turns out to be that loss of communications.

Hope this helps some.

PS: Backups running in the VM (not at the Hypervisor level) don't freeze the VM and thus is not a problem with these running during the day.

You are on the right track, the PSQL 311x errors are network disconnects / communication disruptions between the client and the server.   Last digit can change depending on what operation the client was in (reading data, writing data, etc).  This can be a tough one to fix, but I have seen some oddball items cause this to happen.  We support SentinelOne and doubt it is a problem if you are keeping S1 up to date on server and workstations.

You are on the right track looking at the communications between the switch and the workstations.  You can create these errors by removing the ethernet connection and reconnecting it when the user is doing something in Sage 300 CRE (do it in sampel data, please).  Hopefully, you have a managed switch and can monitor the ports.  When was the last time the switch was rebooted?  Many times, those switches are on a UPS and are up for years.  Have you just tried power cycling the switch?  Are you seeing any CRC or truncated packets on any ports?  You do have the workstations and server on the same network segment, right?  No router / firewall between them?  Propagation delay will cause these errors too.

You can also check the PSQL logs at C:\ProgramData\Actian\PSQL\logs\pvsw.log.  This is just a text file, and you can review it on the server and workstations.  Server is probably clean, but you may find this is happening a lot more at the workstations than you realize.  You may also find other errors that may show up that will point you to other things to look at.

In the past year, I have seen these errors caused at 2 customers due to the backups running during the day when users are in Sage.  If the Sage server is a virtual machine (and I would hope it is), then what backup system are you using?  If it is hypervisor aware, then that could be your problem.  Those backup systems that initiate a hypervisor snapshot (like Veeam does against VMware ESX / vSphere) will cause the VM to freeze for a short period of time, say 5 to 30 seconds while the snapshot is created.  If your backup does that, that is your network disconnect.  The Sage client on the workstation is talking to the server and expecting responses in milliseconds and when the server goes to sleep for 5 seconds, that will generate a 311x at the client (not the server).  The two customers I saw this changed the backups to only run after hours and the problems went away.

A couple of other random thoughts, ensure you have Windows Fast Startup turned off on your notebooks (I assume they are all SSD).  Also set the units to not go to sleep when on A/C. These are longshots but both can be problematic, the first in general the 2^nd with Sage.

Disabling the PSQL cache that was suggested is OK, but another long shot.  Give it a go.

These 311x errors can be hard.  Been supporting Sage 300 CRE for 25+ years and every time I have had to work on it, it comes down to loss in communications.  It can take some time and effort to find, but it always turns out to be that loss of communications.

Hope this helps some.

PS: Backups running in the VM (not at the Hypervisor level) don't freeze the VM and thus is not a problem with these running during the day.