thomas.dickens
New member
- Local time
- Today, 16:33
- Joined
- Sep 15, 2025
- Messages
- 10
Thanks all for your responses. Sorry for the delay in getting back to you - I have been out of the country and away from my computer.
I believe I have been able to narrow down the cause to users closing their laptops/moving rooms without closing the database safely, RATHER than the database crashing. No issues were reported whilst I was away because users reported that they had been extra careful.
We had another occurrence of the locking issue this morning where two users left the main office to go to a meeting. Same error messages. Fortunately it was fixed after both users logged in and closed the database properly (unclear which user caused the issue). This is the first time that it has been fixed without having to wait until the next day.
It would suggest that in the past, all we had to do to fix it was have the relevant user log back in and close the database properly. However I can say with reasonable amount of confidence that in the past, the user I suspected to have caused the issue, was available and logged in, and was unable to have any positive impact.
One change I have made is moving the BE further up the directory, as it was slightly buried away. It is possible that this had a positive effect for this morning's instance.
Thanks. Noted all of your messages above and I appreciate the feedback. I will go back to a system where users copy a central file to their personal drive.
Not at all familiar with running scripts, nor whether my system will allow it, but I will certainly look into it because I now have trust issues with my users!
Thanks all for the help.
I believe I have been able to narrow down the cause to users closing their laptops/moving rooms without closing the database safely, RATHER than the database crashing. No issues were reported whilst I was away because users reported that they had been extra careful.
We had another occurrence of the locking issue this morning where two users left the main office to go to a meeting. Same error messages. Fortunately it was fixed after both users logged in and closed the database properly (unclear which user caused the issue). This is the first time that it has been fixed without having to wait until the next day.
It would suggest that in the past, all we had to do to fix it was have the relevant user log back in and close the database properly. However I can say with reasonable amount of confidence that in the past, the user I suspected to have caused the issue, was available and logged in, and was unable to have any positive impact.
One change I have made is moving the BE further up the directory, as it was slightly buried away. It is possible that this had a positive effect for this morning's instance.
This is the correct way to handle it. Or you could look for the scripts here that automatically download the shared file to the selected private folder on the user's machine.
Thanks. Noted all of your messages above and I appreciate the feedback. I will go back to a system where users copy a central file to their personal drive.
Not at all familiar with running scripts, nor whether my system will allow it, but I will certainly look into it because I now have trust issues with my users!
Thanks all for the help.