Is this normal? I have my computer set to go to sleep after being idle for a while. If I was connected to the ModelManager database before it goes to sleep, the connection is lost when I get back to my computer. What I found is that my computer turns off the LAN card when it goes to sleep (to save power). If I turn that option off, then I don't lose connection to ModelManager.
I've also found that if I unplug the LAN cable while I have Modeling and ModelManager running, obviously both stop working. Modeling, however, will automatically reconnect to the license server after I plug the cable back it; ModelManager won't reconnect automatically.
This behavior has been what we found over the years to be "normal". Once you loose connection to either the db server or file server your are actually logged out and there is no auto-reconnect feature in MM.
There *is* a reason why Modeling and other applications re-establish the connection to the License Server:
The user must be able to save his work - so it is vital to try to re-connect.
On the other side, there *is* a reason why Modelmanager does *not* reconnect to the DB:
When MM starts, it reads the XML + a lot of settings (preferences) from the Database.
The settings influence how a lot of things are initialized in MM.
A "re-connect" of MM is therefore pretty close to re-starting MM - this is the reason why there is no "re-connect" for MM.
Opposed to this, a "re-connect" with a old WM Client makes sense, since the U/I is static and determined by
the startup sequence - no preferences from Database need to be loaded - thefore a re-connect is possible
and available in Classic WM.
You can still sub it the ENH for MM but I think the chance is pretty low that this gets implemented.
Hope this helps.
Thanks Max for replying.
Right now the user is left with a forced notice that the connection was lost. If a "re-connect" of MM is pretty close to re-starting MM, why not add in that error dialog a simple push button option to restart? In this way they get the notice plus a simple resolution. If the re-connect does not have a chance as an ENH what about the above alteration?
The client could also verify if the XML-file was changed since the launch of the client. If not, it could safely reconnect automatically. If so, then it can automatically restart (with or without a confirmation of the user).
Hello Model Managers,
The problem with "re-connect" is that just reconnecting is not enough for Model Manager.
When MM starts, it reads a lot of preferences from the Database (not just from the XML),
and MM initializes a lot of stuff depending on these preferences.
After a disconnect/re-connect, MM would need to initialize itself again - to cope with the
situation that a preference has been changed meanwhile - e.g. because the same MM user
was connected from a different computer. It would also need to load all kinds of "caches"
which are filled when MM starts - because MM cannot tell if these caches are still valid.
And the safest way to initialze correctly is to re-start MM ....
I don't want to say that a re-connect is impossible, but it will require by far more thinking and effort
than one might think. And then customers and PTC Product Management will have to decide
on the worth of this functionality (compared to the effort).
I think that other investments into the product will give more value to the customers,
but that is my personal opinion.
I'm sure that you are correct about the need for re-reading preferences and caches. But from a user's point of view, if the LAN connection is lost, even for just a second, it is a problem-the user just gets an error message.
At a minimum, it would be nice if ModelManager (and Modeling) recognized what happened and presented the user with the ability to re-login; maybe an error box with a question "Connection to Model Manager database lost. Do you want to attempt to login again?". I know that it would only save a couple of steps, but this seems a lot more user-friendly.
Of course, if it automatically tried to re-login (using the same login and password used previously), that would be even better.