Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

Hanging-license issues

Bugs, Known Issues, Open Cases

Last Post by Anonymous 1 second ago

7 Posts

4 Users

0 Reactions

80 Views

RSS

jonyergo

(@jonyergo)

Posts: 22

Eminent Member

Topic starter

We have been having this issue for some time, and every time we bring it up with our VAR, they always say "its just the way Centricity is".

The practice has an issue where we are very close to the maximum users limit on a regular basis. If a users application crashes, or if a user does not log out properly, their license sometimes gets hung up in the MSSQL database.

The VAR-provided fix is to use 2 saved queries on the database server; one to list the currently logged in users (who are using licenses), and the other to remove the license by SessionID. I run the first query to compare sessions and determine which ones are hung up by duplicate workstation ID's or users or old time stamp, and then use the second query to remove that session. This frees up licenses and allows a user to log in.

This is all well and good, but it doesn't solve the root problem, which is in my opinion a poorly designed method of managing active licenses. Yes, I know we can try and minimize application crashes and better educate users to not use the red "X" to close the application, but these things will happen from time to time.

I've heard at other practices, the VAR was able to throw extra licenses at them for no cost to give them more buffer room and prevent users from being able to log in, however my practice cannot do this as their licensing model would be very costly, despite the fact that there are no additional providers.

My biggest gripe is that the "fix" cannot be automated in any way because it requires human logic to determine which licenses could be hung up.

Anybody else having this problem and sharing my frustration? Any suggestions?

Posted : January 13, 2016 4:42 am

vsokoln

(@vsokoln)

Posts: 35

Eminent Member

Our organization encountered similar issues with coming close to and sometimes hitting our max licenses. Rather than purchase additional licenses, we reduced the Idle User Timeout length by 5 minutes at a time to measure impact to the whole. Of course we had to get administrative approval and give advanced notice to the users but I was surprised to see how significant of an impact a 5 minute change made to the licensing. Although it does not provide you a solution to the root cause, it did help us so I thought I would share the information.

Posted : January 13, 2016 5:11 am

mscianni

(@mscianni)

Posts: 10

Active Member

Your not alone. Our clinic had the exact same issues with licensing. Fortunately we were able to purchase additional licenses so for now we are better... not completely fixed but running out of licenses has definitely slowed down. I keep SQL SMS running on my workstation so when I hear the overhead page for users to please logoff if they can, I run the script to see if I can delete any people who may be logged in multiple times. It would be nice if GE would address this as a serious problem.

Posted : January 13, 2016 5:32 am

jonyergo

(@jonyergo)

Posts: 22

Eminent Member

Topic starter

I reached out to MSSQL forums and someone was able to product the following query...

SELECT SessionID
FROM iLicUserInfo INNER JOIN (
SELECT WSID,
MIN(Last_Login) AS timestampField
FROM iLicUserInfo
GROUP BY WSID
HAVING COUNT(*) > 1
) t ON iLicUserInfo.WSID = t.WSID AND
iLicUserInfo.Last_Login = t.timestampField

Running again out test database, it was able list the SessionID's of sessions that in my eyes could be removed. Now, the next step is to incorporate it into a loop to change the "NULL" value in the clearing script using each of the SessionID's it found. A loop is required because it doesn't seem multiple session ID's can be inserted into the script at any given time.

I'm getting very close to automating this!

Posted : January 13, 2016 5:57 am

jonyergo

(@jonyergo)

Posts: 22

Eminent Member

Topic starter

Good news! After seeking guidance at some MSSQL-specific sites, I was able to put together a TSQL query that checks the license table for duplicate user login sessions on the workstations, and clears the oldest session of the 2 or more duplicates.

It's important to note that the custom scripting will not clear the user session if there is only one session for the particular user, however it is possible that the GE-created stored-procedure CleanAppSessions could clear it.

This query can be scheduled to run every few minutes to help automatically clean out stale sessions without having to manually inspect sessions and running them through other queries manually.

I have not extensively tested this, so use at your own risk. I strongly suggest testing on a test database first.

Another way to test is to wait until there are hung users, then run the following query against the Centricity DB, and compare the returned SessionID's to that of what you would have selected.

SELECT SessionID FROM ( SELECT *,ROW_NUMBER() OVER(PARTITION BY WSID + LoginName ORDER BY Last_Login desc) Row FROM iLicUserInfo ) Tmp where Row > 1

Full Query

DECLARE @SessionIdd int

EXEC dbo.CleanAppSessions
WAITFOR DELAY '00:00:03'
EXEC dbo.login_proc
WAITFOR DELAY '00:00:03'
EXEC dbo.sysCleanAppSessions
WAITFOR DELAY '00:00:03'

DECLARE crsr_Tmp CURSOR SCROLL FOR
SELECT SessionID FROM (
SELECT *,ROW_NUMBER() OVER(PARTITION BY WSID + LoginName ORDER BY Last_Login desc) Row FROM iLicUserInfo
) Tmp
where Row > 1

OPEN crsr_Tmp;
--Start FETCH process
FETCH NEXT FROM crsr_Tmp
INTO @SessionIdd
WHILE @@FETCH_STATUS = 0
BEGIN
EXEC dbo.sysReleaseAppSession @pAppSessionId = @SessionIdd

--Grab next record from cursor
FETCH NEXT FROM crsr_Tmp
INTO @SessionIdd
END
DEALLOCATE crsr_Tmp --clean up cursor

Posted : January 13, 2016 11:31 am

carlosjr

(@carlosjr)

Posts: 10

Active Member

Did your solution work?

Posted : September 14, 2016 10:11 am

jonyergo

(@jonyergo)

Posts: 22

Eminent Member

Topic starter

It works rather well. Since implementing it, I have not had any service requests to clean up licenses. It's been in place for over 7 months without any issues.

Posted : September 14, 2016 10:16 am

24 Forums
9,940 Topics
39.9 K Posts
0 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed