Application Updates

[alexmuir]

Hello

A common function in the majority of leading UK accounting software is a check to see who is logged on to the software.
Essentially you click a menu item and the software logs who is currently logged in.
The benefit being that you avoid the grief and hassle caused by applying an update where crucial files are in use.
Hard to believe I know but some users think by shrinking the current application windows they are using , they have logged out!

In A5V10 desktop it would be useful before applying an application update to check to see whether everyone is logged out of the application.


Any ideas on how I would do this?

Thanks for your help. It is very much appreciated.

Kind regards

Alex

[DaveM]

Re: Application Updates

There is a way. it has to do with the .muf files in the app folder on server.
something like this:

cpath = a5.Get_Path()
cmast = a5.GET_MASTER_PATh()
regusers = a5_registration_license_inuse(cmast+"\sales.muf")
runtimeusers = a5_registration_license_inuse(cmast+"\sales.rmuf")
totalusers = runtimeusers+regusers

[CharlesParker]

Re: Application Updates

Hard to believe I know but some users think by shrinking the current application windows they are using , they have logged out!

Well one day in tech support I asked the person what version of windows they were running..they responded "I don't know, yahoo?"
Ok then...

In regards to your question, I would take the approach that I see other desktop programs take, ask with a msg box if they want to update - then if they click yes it automatically closes the program and begins the update.
Your inquiry to update should offer to save the work.
Do I know how to do that?
nope.
I am just offering an idea flow.

[DaveM]

Re: Application Updates

Alex, if they are running shadowed, then you should be able to apply the update to the "data server" and raise the version number by 1. if it is set up right, that will reshadow the next start of the app. That is their update. If you are changing tables fields in some way, you do need them all out of the app.
Or
If you are not using shadowed, they need to be out.

There is a way to shut down all users in the app as well. I just never used it.

[alexmuir]

Re: Application Updates

Hello Charles

Thanks for your prompt reply.

With shadows the update is applied to the server and then as each user logs on next, a message informs them of the update which is duly applied.

The problem is not applying the update, but ensuring that no one user is in the application when you are applying the update to the server.

Many Thanks

Alex

[alexmuir]

Re: Application Updates

Hello Dave

Thanks for your prompt reply.

The problem is identifying who is logged on to the application before the update is applied to the server.
Raising the version number by 1 we do when we apply the update.

I am intrigue by your comment about shutting down all users - could you elaborate please?

Kind Regards

Alex

[CraigSchumacker]

Re: Application Updates

I built a system some years back that I will be re-writing and updating soon.

I created a control panel to collect logged in users, error messages, and screenshots.

In that app, I created a small form that gets opened in the users app called Satellite. It is loaded via AutoExec, but never shows.

The OnInit of Satellite form creates a record in the current users table with computer name, user name, IP, etc.

The OnExit destroys that record.

The OnTimer keeps looking for a .T. in the checkmarked Lockout field. Every 60 seconds, it checks.

If a user tries to enter a Locked Out app, he is refused. Set in the AutoExec script.

If a user is already in the app, and the Lockout is set to .T. while he is in the app, the user is given a two minute warning before the OnTimer closes the app. A screenshot is taken just before the Alpha is closed, recording some info for re-creating a lost record not saved.

Works very well, unless Alpha closes abruptly, or with Task Manager.

If time ever permits, I will write some how to articles on this, but that seems unlikely. It really isn't hard to do; just about all of you have my skill level.

But it can be done. Additionally, there is newer functionality to make it even easier than what I did. I had to make a Visual Basic exe to capture user names and the like, as this was prior to the Alpha Five functions that are available now.

Here are a couple pics for ideas...

CONTROL MODULE.jpgCONTROL MODULE SHUTDOWN.jpg

[alexmuir]

Re: Application Updates

Hi Craig

I should give some background as to why we have the problem.

The problem we have is that despite copying across index files multiple times, some tables on their server still do not see the indices so they cannot produce invoices and we suspect missing indices are why part of the app is running slow.

Kind Regards

Alex

[CraigSchumacker]

Re: Application Updates

You say:

"The problem we have is that despite copying across index files multiple times, some tables on their server still do not see the indices so they cannot produce invoices and we suspect missing indices are why part of the app is running slow."

Others may be more open minded to what you mean, here, but I have no idea what you are doing.

You might want to give a brief scenario (Flow of process) as in, we want this, so we do this and that with the hopes of getting this result.

It almost sounds like you are creating Indexes on the fly...

[Tom Cone Jr]

Re: Application Updates

If one opens the networked database directly on the server. The File menu of the Alpha control panel has an option to display "Database information". This will show you if any of the tables are open on the server. Unfortunately, it does not tell you which workstation(s) are using the tables, but at least you can easily see if no one has a table open.

[WokingJon]

Re: Application Updates

Alex,

I use this simple bit of code to check no other users are in the system before rebuilding indexes:

'If multi user, ensure only one user logged in before rebuilding indexes
if (:a5.Get_Master_Path()="") then
	'continue
else
	path = :a5.Get_Master_Path()
	user_count = a5_registration_license_inuse(path + "\arma.rmuf")
	if (user_count > 1) then
		msg = "In order to Rebuild Indexes, all other users must logoff from the system. Please try again."
		dim q_msg as n 
		q_msg = ui_msg_box("Index Rebuild Cancelled",msg,UI_ATTENTION_SYMBOL+UI_OK)
		end 
	end if
end if

[Raymond Lyons]

Re: Application Updates

I no longer have a real server to test on, but I do have v10.5, v11 and Runtimes for both, so on a single PC I can open many instances of the same database and test variations of the code snippets suggested in this thread, as well as the one in the Help file [all of them really amount to the same thing, using a5_registration_license_inuse()]

Trouble is, at least in my environment a5_registration_license_inuse() does not produce what I consider to be accurate information. That is, for the Runtime (Rmuf) I get "0" when in fact the Runtime has it open twice, and for the full version (v10.5 and v11) I get "1" when each has the same database open, so I would think it should be 2 for both the full version and the Runtime. Unless of course a5_registration_license_inuse() only counts A5 on different computers having the database open, not different instances of the database being open on the same machine. And yes, there can be legitimate reasons to have a database open more than once on a given machine. Oh well.

And as someone mentioned, home grown methods I have seen (and used) have no way of dealing with A5 crashing or being closed via the Task Manager. If one has access to admin functions on a server there is a way to see if files are open, and even which user(s) has/have it open, and if desired the files can be closed on the server from the server. So I suppose there might be a way of building a function in A5 to access server functions to see if particular workstation has a database file open on the server, and if in a different A5 app for just this purpose even close the file(s) on the server. But IF there is a way to do this, I don't know it. Then there would also be the issue of what if Joe User was actually doing something when you closed down the files? The only times I ever closed down files this way (by accessing a server remotely) was when I was pretty sure the culprit was home sleeping at 2:00AM and had just left the database open at the end of the day.

For what it is worth, my testing snippet:

Dim user_count_Rmuf as n=0
Dim User_count_Muf as n=0
user_count_Rmuf = a5_registration_license_inuse(file.filename_parse(a5.get_name() ,"dpn") + ".rmuf")
user_count_muf = a5_registration_license_inuse(file.filename_parse(a5.get_name() ,"dpn") + ".muf")
msgbox("Rmuf",str(User_count_Rmuf))
msgbox("Muf",str(User_count_Muf))

Ray Lyons