How do you define "entering data"? Navigating between screens? Typing? Executing scripts? Time spent with records open (i.e., locked)?
There are a lot of variables to such a metric, and not all of them are useful. How do you propose to measure the "actual time working"? If a user is staring at the data entry screen, reading, copying data to a piece of paper while he talks to a customer, by definition, he's working, but there's no way for the computer to tell the difference between that and just staring at the screen while he plays Candy Crush on his phone. Similarly, if he's running a report that takes, say, 3 minutes, does he get credit for that - even though he's not actually doing anything at the time? What about navigation? If he goes from the Main Menu to Data Entry, looks at something for 3 minutes, and back to the Main Menu, does that count as 3 minutes of "working" time?
And for what purpose are we developing this metric? If the user stays logged in all day, but ends up taking customer calls that don't require database interaction, does that mean he's a poor performer? I recall our Help Desk personnel gratuitously closing cases that weren't solved, just to get their closure time stats down because they were being hammered about it. This sort of tracking is similarly open to abuse. I can see someone just clicking around the database to boost his "working time" stats so management will get off his back.
I'm honestly not just trying to be snarky here. It's important to understand that this is not a simple concept. Requests like this usually come from management trying to develop some kind of metric on people in a call center or similar situation. But they're fraught with difficulty, and the answers you can provide are usually pretty poor. We'd need more information about exactly what kind of solution this is and what kind of "work" the users are expected to be doing in order to offer any sort of decent advice.
Remember: Lies, da## lies, and statistics ...
Thanks for the reply Mike
I kept my question basic because i need to figure out if its even feasible to do such a thing.
The data collected will be used for but not limited to
-Forcing the application to quit after a given period of time based on whether it is connected remotely or locally (not privilege)
-Closing the database after a given amount of time (With considerations other then just time. ie time and user)
-logging of database activity
If it was a simple concept..... I would'nt be asking here
Forcing the application to quit can be done through the FileMaker Server setting for idle time.
If you want to log database activity, you can do that through a log table and inserting the scripting action into each script (basically, you save whatever information you want at the beginning and maybe end of each script).
You can run an OnTimer script that simply resets a timer each time the user takes an action, and, if it times out, close the file.
However, forcing the database down is often not a good idea. If the user has a record open, it can result in lost data, or, in more extreme cases, even a corrupted database. The real question is, why do you need / want to close the database? What's the business requirement for doing so?
Ill take it down to this question.
Is it possible to create a script that calculates the time when a user stops interacting with the database and some other time?
It's software. Anything is possible.
One approach you could take would be to insert a timestamp into a field in the user's Sessions record called (for example) lastInteraction. Then have a timestamp equal to previousInteraction, which is the value of the interaction before the current one. The difference between the two is the time between interactions.
Another approach would be to create a new record in a table each time the user "interacts" with a creation timestamp. Then you have a history log of every "interaction". You can then do whatever you want with those data.
The nasty part of such a system is you have to insert the action to record the timestamp into every action the user takes. If it's a script, then you have to add it to the script. If it's navigating to a layout, it's an OnLayoutEnter trigger. If it's a keystroke, it's an OnObjectKeystroke trigger. If it's a record commit, it's an OnRecordCommit trigger. You can wind up with a lot of overhead doing this, if you're not careful.