This sounds like your IT support staff has imposed a local domain policy on idle terminals to force a Logout rather than a Sleep. In a fight between Access and Windows, Windows always wins. When the domain policy says Logout, then your two choices are to (a) help the app to gracefully shut down or (b) talk to your IT staff about whether they would consider a Sleep rather than a Logout. NOTE: Depending on whether there is any sensitive data available through your network, the odds of (b) diminish quickly, since it implies that something could still be active.
I used to work with the U.S. Navy. The Navy Enterprise Data Center - New Orleans had one of those "Logout after X idle" policies. What happens when those policies kick in is that Windows visits every task associated with your session. The task gets told by Windows to shut down. The task then has a chance to execute what is called a "Rundown" in which it is allowed to close everything. My comments below about "hardening" your app, if you implemented such a thing, would occur during the Access Rundown phase.
Some tasks, however, do not intercept that shutdown and thus leave themselves running. In a second look, if the task doesn't shut down, Windows forces a Process Exit, which can leave things dangling. Even if your system isn't set up for a Windows Pro-level operation, you can see the same sort of thing using "Win Start >> Power >> Restart" and watch active tasks start dumping themselves right and left. If you are on Win Home, some task "hangs", and you have to use the CTRL/ALT/DEL method (3-finger salute), you get a Logout option. At the end of that per-process loop, all of your tasks are removed from memory in a way that cannot be reclaimed. That happens to me on some older games every now and then.
What you can do to "harden" your app and prevent the app from becoming completely broken is to have any open forms include some event code that detects the shutdown and does something to prevent corruption or breakage.
support.microsoft.com
You have the Unload and Deactivate events during which time you can close records or impose an Undo on a dirty form. Your last chance would be to catch something in the Close event, but that is stretching since some actions might by then have become untenable. There are ways to deny the unloading of a form, since that event allows a Cancel option. However, in that case, the Access app gets caught by the second part of the process shutdown loop, with a forced exit that CANNOT be blocked.
This "hardening" has to be implemented for every form that can be open. If you have a report that (unwisely) does something active behind the scenes while it is open, this "hardening" would apply to that report, too.
