Per the documentation, the time for unlocking records on shared files can only be changed on each computer: Note: When the timeout is modified after the database has already been changed to a sharable database, the change applies only to the current computer. You must repeat it on the other computers on the network if you want them to use the same settings.
That implies that even a Critical New Generation won’t change it. Is that true? Meaning the only way to change it globally is to detach the file(s), make the change, then re-share it, requiring everyone to replace all involved files.
I think a critical new generation will change it, but I’m not 100% sure. Probably 98% sure. Ok, I haven’t tested it, but I just looked at the code, and I’ll up that to 99% sure.
What the documentation is referring to is if you simply change the setting and then press the Ok button, but without doing a new generation. I think that new sharing generation didn’t even exist when that documentation was written, so that could probably be revised.
After several tests, I can say with some certainty that the Auto Unlock cannot be set or changed via New Generation; critical or non-critical. Fields, forms, procedures all change as expected.
While helping to trouble shoot a very slow shared setup, I ended up here again.
I had crawled the (ever useful) logs to look for any clues. I found that yesterday a user accessed a record but did nothing with it for 2.5 hours. That whole time, it was hitting the server every 30 seconds to keep the record locked and unavailable to others. So that’s about 360 unnecessary hits in that time.
Then something was changed and the activity went idle again with another long string of 30 second hits. During this period another user logged on and was briefly active while having to compete with those 30 second hits. Then that user went idle too and there were four hits per minute to keep records locked for those two.
Overall they repeated this for quite a while with occasional activity. Their idle time was the greatest use of the server.
I was also logged on and synched but accessing no records. Nothing beyond my synch was shown in the logs.
It turned out that no time had been set for Auto Unlock in Database Sharing Options.
I applied a 45 send timeout and clicked OK.
As noted in the thread, it’s unclear as to when and how such a change is applied. Watching the logs, it looks like it was applied on the server immediately. For the first time, the server has quiet spells even as users have been logged in and were previously active.
Hopefully this is useful to anyone else dealing with a slow server, but it also suggest that a default time out should be in the Database Sharing Options rather than a blank. As it is, the default seems to be a perpetual lock.
And another shout out to the logs. I can’t count how many times they have provided the clues to resolving sharing and web serving issues. If you’re running a server without enabling the logs, you’re working with a disadvantage.
There’s not going to be any performance impact from a single quick access every 30 seconds. Maybe that would be 10 milliseconds every 30 seconds, which means a performance hit of less than 0.05%. In other words, entirely undetectable.
It turned out that no time had been set for Auto Unlock in Database Sharing Options.
FYI, the Auto Unlock feature is not what is causing the activity every 30 seconds. That activity is to make sure that the record is unlocked if the user turns off their computer or disconnects it from the network. Before this was added, if a user did either of those things, any locked record would be permanently locked, and could only be unlocked by manually killing the lock with the Server Admin wizard.
Of course Auto Unlock does indirectly affect this, since once Auto Unlock kicks in the record is no longer locked so the keep alive is turned off.
Yes, that is intentional. Auto-unlock can be disruptive to the user, so I don’t think it should be turned on by default.
Since you seem to be concerned about performance, don’t forget that there is some (small) performance hit from the logging process itself, especially if you have fine grained detail logs enabled (which you must have to see this keep alive activity). There’s no free lunch.
