The tUsers thing is a great Idea using the windows login...
As long as you're doing that, you might as well use the api call to get the user credentials, then there's no manual login at all. IMHO, it's more reliable than the Environ function. My last couple of dbs took this approach coupled with a user table. Consider learning how to create a custom object (dbUser) and give it properties for Fname, Lname, emplID, email, UserLevel, whatever. You can write dbUser.EmplID to any tracking field for any action such as writing to a record. Any time you need to check a user level for allowing form views or form controls access, just refer to dbUser.Level or whatever you call it. I also got the machine ID (another api) but didn't us it much.
As for backups, I used Windows Task Scheduler on a machine that was dedicated to running several nightly backups because this machine was never turned off. WTS seems to have the capability of running tasks even if one is not logged in, but I never tried it. My schedule event used a shortcut with a cmd line switch "Otto Mayshun" (dumb pun?). If the machine opened the db, a bunch of code was averted by checking the db Command property (it signifies that a cmd line was used in the db opening). It didn't matter what the Command value was to me, just that it wasn't an empty string or Null. When the backup routine runs, a command line (batch) file copies the db and over-writes to ensure the day's data is captured. Then all the tables update via ODBC. Then the batch runs again to over-write the backup only if the update goes off without a hitch. This ensures the day's data plus the ODBC updates are captured and all is ready to go at the start of the day.
Maybe some of that will get you thinking...
Last edited by Micron; 03-30-2017 at 12:45 PM.
Reason: clarification
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.