It's governed by the users' Role being authorised to access the Feature called 'User Login Status', which you'll find under Accounting System Manager -> Administration in the Features list in the Sage SAA tool.

The feature only has a single target - that being the Disconnected Login screen; so giving someone access to that feature isn't going to inadvertently give them access to something they shouldn't have.

Hi Chris,

Thanks so much for getting back to me so quickly, much appreciated. Just going to test it and will verify your answer once it's done.

Do you know if it is possible to run a job in SQL that could kick off any disconnected logins every few minutes? The solution above is mighty but to do it automatically might be even better if it were possible.

Thanks again,

Paul

Hmm. Maybe.

What you're looking at in the Disconnected Logins screens are entries in the SYSUserLogin table which aren't active. How Sage 200 decides which ones are active and which ones are not active ('disconnected', in other words) we'll come to in a minute.

When you choose to 'log off' a disconnected login then behind the scenes these things happen:

1) Sage 200 finds all the entries in SYSFeatureAreaUsage where SYSFeatureAreaUsage.SYSUserLoginID == SYSUserLogin.SYSUserLoginID and deletes them. In current versions this step is academic as I'm pretty sure this table is no longer in use.

2) Then Sage 200 finds all the entries in SYSActiveLock where SYSActiveLock.SYSUserLoginID = SYSUserLogin.SYSUserLoginID and deletes those.

3) Finally the entry in SYSUserLogin is deleted.

That's all well and good but, as mentioned above, we want to be sure that we're not deleting entries that are still active. There's nothing in SYSUserLogin to indicate this status; this data is actually stored in the Sage 200 Configuration database in a table called tblSessionInfo.

Imagine we're in SSMS and running this query against one of your Sage 200 company databases (and also assume that the configuration database is called 'Sage200Configuration') :

That's essentially how Sage 200 is deciding what qualifies as a Disconnected Login.

It's not difficult to see how you could build a stored procedure from that : run the query above to populate a temp table, then use it to do a 'delete-with-joins' across SYSFeatureAreaUsage, SYSActiveLock and SYSUserLogin.

Whether this actually solves any kind of practical problem is another matter. What has always been a problem for my clients is when users go home but stay logged in to Sage 200 - therefore remaining "active" and preventing someone doing a month end or something like that (which is a problem I've solved, but that's by-the-by). Are disconnected logins causing a particular problem for you?

Wow Chris, really appreciate the detail in the answer.

We have a sales team that can get locked out of their own sales orders or quotations if their connection to Sage drops and this has become a more frequent problem (connections dropping) with working from home. In the west of Ireland, internet coverage is inconsistent, to put it mildly.

Kicking users out that stay logged in is another issue that I would love to solve. We have had to call people at 6pm in some cases to get them to log out to enable month end to be done.

Interesting. There might be a more elegant way of dealing with that... maybe a very targeted and very restricted way in which a user could unlock their own orders/quotes after a crash. Hmmm. I'll have a look at that when I get the time.

As an aside : The 'maintenance window' solution is something I originally wrote for one of our largest Sage 200 clients (40+ users over 3 sites) who were always having month end problems with users still logged in at 7:00pm or what have you. It works great for them and we've sold it onto a few other customers of ours. We've thought about making available outside of our own customer base but there's a couple of reasons why I'm a bit reluctant to do that  - the main reason being that in the case of our customers we know exactly what 3rd-party stuff they'll have installed - usually stuff we've written - and we know that it won't cause an issue with the 'maintenance window' thing. But for users outside of our customer base that would become a bit of an unknown quantity.