> >Does anyone know of some way to kick all my users out > >of a multi-user application when performing maintenance? > >Although you send an announcement, some space cadet > >always stays in the app causing the maintenance to bomb. > >We are running Win NT. > Another method I have used with some success is to check the "Temporary" > files directory VFP uses to store temporary/working files (if on the > server). This assumes you have set up a CONFIG.FPW file with > TMPFILES=F:\TEMP or something like that. This works best when this is a > completely "disposable" directory. Again this only works if the temporary > files directory is on the server (not as efficient as having > TMPFILES=C:\TEMP). I would then do a "NDIR" (Netware directory) that would > show the OWNER name of the files. If there are too many files (probably > old files that were not deleted because of improper exit of an app), I will > start deleting any files with dates over 1 day old (very easy form > Explorer). Then try NDIR again. You could then track down the sleeping > user. Unfortunately, NT hasn't reached the stage that it knows who owns files. I also use this method with Novell servers, but it simply doesn't work with NT. The best that you can do here is to detect that yes, some users have the application open. > One last technique, is to have your app create a temporary "user file" in > the app directory when the user logs-in then deletes it when the user quits > the app. Check for these filenames to track down the user. This assumes that each user will only be in the application a single time. The mechanism that I settled on was to have each user assigned a unique ID on the way into the application. As part of my forms/users handler, I have a table store the username, uniqueid, and screen name. When the user starts a screen or the application, a record is added. When the user closes a screen or the application, the record is deleted. MULTILOCKS is set on, and the records for each user are also RLOCK()ed by that user. I have a second program display the contents of this table with a 1 second refresh rate. It also ensures that it cannot issue an RLOCK() on the records. Any record that the second program can issue an RLOCK() on, it deletes (this happens if the user turns off the machine or experiences some error that causes the table to be closed without the record being deleted). This works _really_ well. /Paul