Timer in executable on network

[Puebles]

Hello,

I have an issue of users leaving a program running for days. This prevents me from updating table structures, indexes, and issuing an updated executable. I have put a timer on the main screen which checks to see if I have set a variable in the "Control" table which should trigger a shutdown. The timer and shutdown works flawlessly in the VFP development environment. However, when run as an executable from the server the timer does not fire.

OK, I just amended this post after finding an article that explains that timers do not run in an executable. So, my new question is "How do I force a shut down?"

Your feedback is appreciated.

 

[Olaf Doschke]

It now really depends on what Control.Logout is. If it's the logical type field of a control.dbf you still need to get at the current value of it.

There are many buffering and caching mechanisms hindering you to see the dbf value, CURVAL() would be one way to see the CURrentVALue of the DBF, if the Control workare is buffered. Obviously Control would be bad, if it would be a cursor of a query INTO CURSOR result, only under special conditions a query INTO CURSOR will be the dbf and also change, then the DBF data changes.

Bye, Olaf.

 

[dbMark]

Glad you have the timer working. On the side point of not knowing which users haven't exited, if you have access to the server then you can query the server's c:\windows\sysnative\openfiles.exe to report who has certain files open. Sysinternal's ProcessExplorer (now with Microsoft) if run on the server can display all sorts of server processes which can reveal files in use.

 

[Puebles]

I do not have that kind of access. However, the updated program will show me who is logged in. Combined with the auto shut down I am set. Now I just need everyone off one time to update the executable.

 

[Olaf Doschke]

Well, let me once more point back to another strategy of not storing your EXE server side for execution, but put an ._XE file there, just to let users (or a batch script they start instead) get the current EXE local and start it there. That way you can always update the central ._XE file, even if users are still running their copy.

Bye, Olaf.

 

[Mike Lewis]

Glad to hear you've got past that part of the problem, Puebles.

Regarding the testing of the logical field in the control table: Let me recap what I mentioned earlier.

It's possible that Program A might set that field to .T., but when Program B reads it a few moments later, it still appears to be .F. The reason is to do with buffering and caching - never mind the details. The workaround I use is to use CURVAL() to test the value. So, instead of saying [tt]IF Control.Logout = .T.[/tt], you say [tt]IF CURVAL(Control.Logout) = .T.[/tt]

The problem is that CURVAL() only works on tables that have been buffered. So you also need to put the table in a buffering mode, for example like this: [tt]CURSORSETPROP("Buffering", 5)[/tt]. You also need to have first [tt]SET MULTILOCKS ON[/tt]. The is true even if the table is read-0only. It might seem strange buffering a read-only table, but that's the way it is.

If you don't feel comfortable with the above, then use the other approach: create a small file - it doesn't have to contain anything in particular - with a given name in a given directory. Then, Program B, instead of checking the value of Control.Logout, checks for the presence of the file - using the FILE() function.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads