As Randy suggests, you need to look at the versions you are running.  With 2014 you should be killing the mysqld.exe process, not the mysqld-nt.exe process.  That one was for 2008-2013.

Why is the program running at night?  Do you have staff on 24 hour shifts?  If you are not using the program close it.

When you leave the program open, not using the computer, and a computer is set to sleep it's hard drive or network card, I've seen disconnects with the database that cause fatal exceptions when attempting to use it again.  Because you are not getting the crashing until overnight, I would look at this as a possible cause.

The administrator runs all night due to shifts, but the users log off daily. There are NO problems with the administrator account, ONLY with the LOGGED OFF users who are trying to log on.  NOTE:  This does not happen to all the users who are logged off.  For example:  User A & User B are logged off and User A can NOT log on due to phantom, but user B has no problem logging on.  

My error, I should have typed mysqld.exe as that is the one I have been deleting.  

Other than Sage 50 Premium 2014.2, I do not know what versions you are requesting.  Please advise.

I think that they are noticing that the duplicate login, when they are trying to log back on in the morning.  I suspect Richard's theory is the real cause, the power management shuts down the network card sometime overnight, then it crashes in the morning.

If the administrator is logged in every night, you could try having them run a backup at the start of their break.  This requires 'single user mode' and absolutely guarantees that everyone is logged out.

Once you have verified that the system is in single user mode at least once overnight, and there's a backup file in your 'backups' folder and the problem is still happening, I'd want to help you troubleshoot further.

Based on your description, everything should be working ok.  A typical phantom user is usually one that is not elegantly logged off.

However, I work with third-party programs and if you open a third-party program and log on as User A, then open Sage 50 and try to log on as Use A, you will not be allowed in due to the "phantom user".  In this case it is not a phantom, just another program logged in as the same user.  Log into Sage 50 first then the third-party program and it is not a problem.

Try Randy's idea of doing a backup.  This closes and opens the file to get to single-user mode and when going back again.  See if that helps.

In regards to your comment about power management, when the remote user logs off after the shift, the remote computer is turned off.  The administrator computer is on and never goes to sleep.  

It is not an option for the administrator to change to single user mode and log off at the end of every shift. Shifts stagger and overlap, so there is no down time to accommodate this.

My research has shown that this has been a problem in Sage for years.  Is there a permanent fix for this problem? Has Sage worked on this?

In regards to your comment about power management, when the remote user logs off after the shift, the remote computer is turned off.  The administrator computer is on and never goes to sleep.  

It is not an option for the administrator to change to single user mode and log off at the end of every shift. Shifts stagger and overlap, so there is no down time to accommodate this.

My research has shown that this has been a problem in Sage for years.  Is there a permanent fix for this problem? Has Sage worked on this?

Hi Richard

All remote computers are dedicated to Sage and there are no other programs requiring any log on or user name input.

Yes it has been a problem for some users but it is usually traced down to the network connection problems we have been discussing.  You are now indicating the users are logged in remotely.  How are they logging in?

If you are using remote desktop, then all work is done directly on the server.

But if they are logging in via VPN and accessing the database through a redirected drive letter, then this is probably the issue and the database is not logged off properly due to write problems across the internet.

If you can take the time to stop the mysql process when this happens, and the admin computer is the only one on overnight, I am not sure why the admin can't take the 1.5 minutes or so and hit File, Switch to Single-user mode and move it back again to multi-user mode even if he/she can't take the time to do a backup.  If the problem is happening each day, I would make the user do that work to test.  I would also suggest the person select File, Properties to see if anyone is logged in at the time.  I hate to say it that way but we can only give you some suggestions to try to see if it helps.

BTW, logging into the file as sysadmin in single-user mode usually clears the phantom users without having to kill the mysqld process.

We do not use VPN

We do not use remote desktop.

We are using LAN to connect to administrator computer.

In regards to the 1.5 minutes it takes to hit file, Sage, in it's wonderful wisdom has made this much more difficult than 1.5 minutes, hence my reason for asking this question.  

As the administrator, I can not just change into single user mode as other users are using the company.  I can only switch to single-user mode once they have logged out. I assume that Sage has not thought of the administrator taking control and logging users off.  An abbreviated description the "1.5 minutes" means physically travelling to every computer on the system and logging them off. This is a large building and not everyone is sitting in front of their monitor.  Returning to my desk and changing to single-user mode, TEMPORARILY fixing the BUG, and then travelling back to every user to log users back on.  We have tried to set up remote desktop for me to take control of user computers to shut them down from the administrator computer but this takes as much time as physically travelling to each user.  Also, by physically travelling to every user computer, I can put a sticky note on their monitor to tell them NOT to log on (which happens during my travels to every user).  

This time consuming, temporary fix puts our company on hold too often.  

So in short, I know to temporarily BANDAGE this Sage glitch, but I also know this has been a problem Sage users have had for years.  I really appreciate the suggestions and comments, but I was hoping, that after years of Sage users struggling with this, there might be someone out there who knows what programming changes can be applied to PERMANENTLY this.

hmmm - not much different then having a scheduled shut-down (same time every day) to do maintenance on equipment. Can you be doing a CVI vehicle inspection while the delivery truck is running becus driver can't stop dong his delivery route? Rather than physically travelling to every computer perhaps having a pager type system would work better if you are unable to have a scheduled backup period. Then everyone can be alerted to log off within the next half hour or so and then alerted again to log on when backup is done.

I doubt Sage will do anything to help with your problem as it is not an issue for most users. Yours is a unique case and it seems that until you try the backup procedure then troubleshooting the phantom user issue just becomes haphazard. It might be something you need to do (remote logging off all computer) for the first few times to see if it resolves the issues - even if it is a lot of work initially.

CPS

Over ten years ago, when they brought out the first multi-user version, I asked the developers to allow the sysadmin control over the computers and other user id's to all for shutting down, setting up of custom forms and user preferences from one computer logged in as sysadmin.  All the people I spoke with are gone now and they are not looking at the request list much to get ideas on what we want in the program.  You can use File, Properties to see who is logged in and only go to their computers to get them out, but it is still not an ideal solution (and I would let them log back in again but I don't know your system there).

When you said, remote, I assumed a different building/city/province, not different computers on the same network cabling system.

I thought we were also talking about the admin who is managing overnight, not necessarily during the day when more users are on the system.  If users are leaving the office for the night and not shutting down the program, then either that is a company policy that needs to change or that is just lazy staff and they need to be retrained.

Larger databases will take longer to open and close.  Because you have not given us any frame of reference on anything like that (number of users, size of file, etc.) I was going with the typical system when I said 1.5 minutes.

I guess I am out of options short of tracking network cables and ports on switches as being culprits and I haven't done that kind of work since the early 2000's.  Of course, that takes longer than one night of testing the switch to single-user mode and back again.  Sorry I can't help further.

What Sage needs to do is elevate the sysadmin user to have rights to MySQL's  SHOW PROCESSLIST.

This command allows IT staff control threads associated with mysqld,  one of which is to identify and KILL sleepy threads (users)

Well... the Windows system administrator already has the power to violently disconnect the database.

I think everyone would be better served by something more user-friendly for non-geeks, like QuikBooks' Messenger.  It can send a message to a another client program that tells it to log off.  

It apparently doesn't *always* work, since they also have instructions on how to get rid of 'phantom users' by restarting every workstation and the file server.

I've seen this problem completely solved at a client site, by using Terminal Server to run (Simply Accounting 2010 at the time).  

- No more random disconnections, since the client and server were one physical computer.  

- Problems at a workstation, including kicking the power cord out or tripping over a network cable, would cause no loss of data.

- When the administrator really needed anyone logged out, they could just log the user off.  

- Print form files were stored in one, local place with the installation.

- Printer drivers and screen formats at different workstations, was no longer a problem.

It's something you may want to consider, anyway.