#804 Auto close the database after x minutes

[dave]

I think I asked about this some years ago, and it wasn't done then, but I can't find that thread. In any case, is there a way to "auto-close" a database after so many minutes of inactivity (just like the lock function)?

I run across home and work networks, and when I forget to close a database, then want to edit it at a different location, I can't (or shouldn't) do so. My mistake for not closing manually, and it doesn't happen often, but when it does, it's annoying. The ro/rw thing is nice, but it doesn't really give the same sense of security when I go to edit. Great program, I use it a lot, hence the desire.

Thanks.

[Rony Shapiro]

Funny, I've never had this problem when locking a database on one PC and editing it on another. Effectively, there's no potential for corruption, since "locking" it means flushing the database from memory to the file, and "unlocking" a database means reading from the file when unlocking. The major difference between locking and closing is that the former implies the last used database when "unlocking", whereas with closing you have to specify it explictily.

If there is a case for implementing "close" vs. lock, then my main concern would be how this would interact with the locking mechanisms we already have:
Timeout
Workstation lock
* Minimize
Do we want to support both closing and locking under each of these events? Either?

[dave]

Just a user perspective of course, but I see value from both, for different users and reasons. To me, locking would be the less valuable of the two, as it's just as easy to open a new instance and log in as it is to select and unlock. But, if I only used it on one machine, and used it constantly, I would probably find the lock more useful. Perhaps I overestimate the need for closing, based on your explanation. That said, as an old computer guy who's had to fix a lot of corrupted data, I'll probably always feel more comfortable with a database that I can see "gracefully closed". Perhaps the only other benefit would be one fewer running process when the app is not being used.

[Rony Shapiro]

I think that as a "computer guy", you're assuming too much semantics on the term "lock". Keep in mind that password entries are small, and even a "database" of hundreds takes up a few 10s of kilobytes.
This means that we can (and do) read in all entries into memory (kept encrpyted in RAM except what's displayed) when a database is "opened", and write it in entirety when closing (or when as single entry's changed). So chances for corruption are really minimal.

But do keep offline backups, please!

[dave]

Understood, as you explained it, thanks. I did not before your first response. I'd still like to see an auto-close, but acknowledge that there is probably little need for it. Facts notwithstanding, my OCD nature will not allow me to be comfortable where there are open database apps that are not currently used, but I can live with it if that is all that's required to use a great app. Thanks again.

[Andy]

Not being the sharpest tack in the box, I may have missed the reasoning about not closing all icons. I have family members who will consistently have 3, 4, 5 or more cases of the pws icons on their toolbars, most hidden in a drop up/down. It’s just not in their nature to save then close them before they accumulate. If it reaches "timeout", the icon, and instance, should disappear after saving. Similarly on workstation lock it should save and then close. Much cleaner and easy enough to click open the single shortcut icon on the desktop.
BTW I can’t find any timeout feature in my program V3.38.02
Thanks for the greatness.

[Tim H]

I have never seen the value in locking a database instead of just closing and exitting. The amount of user interface interaction required (on Windows) to launch and open a database is basically the same as what is required to unlock it. Leaving the database on the taskbar but closed only indicates to a casual snooper that there is something of interest here while closing it puts it "out of sight, out of mind."