Another Sage 50 user or Workstation is Accessing this Company…

Another Sage 50 user or workstation is accessing this company area or performing a similar company process. Please wait a moment and try again. If you believe you received this message in error, have all users exit Sage 50 and try again.

We are experiencing this exact issue.  I’ll be looking more in-depth to see if I can narrow it down.  A cursory Google search for:  sage “pt.lck” brought me to this forum post and the post you replied to about a month ago.  These problems began after the upgrade to 2020 for all15 users here.  Sporadic.  Sometimes the backups fail as well.  The backups are supposed to get everyone out, from my understanding, but it doesn’t seem to work properly.  I have gone as far as total (complete) reinstall on the server, and workstations, with no luck.  So there’s something else going on.  Maybe it’s a simple problem, and I’m overcomplicating it but I am going to start looking into why Sage just disappears.  The hint is probably in that.

I have a PT.LCK that is owned by a different user than the user that created the SUA00021.LCK file.  I checked the user that created the SUA00021.LCK file to see if Sage was running and it was not “visible” on the desktop.  I terminated (taskkill /f /im peachw.exe) on the workstation.  Did not let go of the SUA00021.LCK so I then had to terminate forcefully Actian (taskkill /f /im w3dbsmgr.exe) and restart it (net start psqlwge).  Once Actian/Pervasive was restarted, the lock on the SUA00021.LCK file was let go and as soon as I renamed it, users were able to launch Sage again.

Another Sage 50 user or workstation is accessing this company area or performing a similar company process. Please wait a moment and try again. If you believe you received this message in error, have all users exit Sage 50 and try again.

— Sage 50 Accounting

6 Comments

Found the issue to be when a computer locks the SUA000021.lck file and doesn’t open is when the .Net Framework needs to be updated. Once those updates were completed all our users were able to use Sage without locking the SUA000021.lck file. Hope this helps out anyone searching this issue.

Travis – thanks for the tip. I’ll take a look across the the systems on the network and confirm if there are .NET Framework updates pending an install or reboot. Thanks again!

Hi Rich, just had this issue this morning with our client. All three staff members were having the ” Another Sage 50 user..” pop up error. Followed your steps – killed the w3dbsmgr.exe and restarted it on one of the users computer not the server and it did the trick.

It removed the SUA000021.lck file and now all three members are able to log into Sage 50.

Thank you for your post!

Santi –

Thanks for dropping by and leaving a note.

Curious what version of Sage50 you are on (2020, 2020.1, 2020.2, 2021, 2021.1). Looking at the 2021 update here soon. Was hoping this would be resolved in the newer versions. Still makes updating the server it runs on a pain, especially when I need to reboot it for patch management.

Hi all,
I think we’re having the same issues. Symptoms: Users will start receiving “another sage 50 user or workstation is accessing this company area”. The only solution (which is a real pain and wastes everyones time) for me is to reboot our Peachtree server, then have each user (10 users total) reboot their PC.

I haven’t looked into the w3dbsmgr.exe, would that be my next step? If all I had to do was logon the our users PC and restart that this would save some headaches.

Asking users to reboot their PC’s at 10am when they have outlook, excel, etc open isn’t an ideal solution because Sage 50 isn’t playing nice!

Thanks all for the input.

Generally, what I’ve had to do on a workstation is:

1. Kill peachw.exe process on the workstation (taskkill /f /im peachw.exe)
2. Kill Actian database process on the workstation (taskkill /f /im w3dbsmgr.exe)
3. Restart Actian (net start psqlwge)

I determine which workstation I need to do this on by looking at the SUA000021.lck file on the server to figure out who owns that file.

Based on who owns the file, I connect to their workstation and run steps 1 and 2 above. To find the owner of a file, in explorer you can right-click and go to Properties and look toward the bottom.

From command line, I use dir /q SUA000021.lck to show me the owner of the file. You can also use openfiles /query /v | find "SUA000021.lck" to get the user with the open file and the lock, and access mode (read/write). Hope this helps.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.