>> >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

This takes a bit of planning and coding, but I believe that I have found the best solution.

Create table and call it SYS_USER.DBF (the fields are unimportant)

At the start of the application
PUBLIC sys_proc

DO WHILE ....
STORE .F. TO sys_proc
SELE 255
USE SYS_USER SHARED
(255 is an arbitrary number, the highest expected area to be used)
.....
(rest of your app in some kind of looping structure to always eventually return to for reseting of sys_proc and SYS_USER)
ENDDO

In your maintenance routines,
STORE .T. TO sys_proc
SELE 255
USE SYS_USER EXCLU as one of first lines
then
STORE .F. TO sys_proc
SELE 255
USE SYS_USER SHARED as maintenance program exits

In your error trapping routine, have something like

IF SELECT()=255 AND INLIST(ERROR(),1705,3)
CLEAR TYPE

IF m.sys_proc
WAIT WINDOW "Unable to run maintenance function due to users still in application, press any key to return..."
RETURN TO MASTER
ELSE
WAIT WINDOW "Unable to run application due to system function in process, press any key to exit..."
CLOSE ALL
CLEAR ALL
QUIT
ENDIF

ENDIF

The code is not exactly what I use (off the top of my head) but is close. Hope this helps//:^)