Lock file shows 'admin' user active for all clients

[pondlife]

We have a split ACC2010 database, with the back end on our server and 5 front ends on 5 client PCs. I hadn't run a compact/repair on the back end for months. When today I tried, I got the 'database is locked' error. The lock file showed 'Admin' logged on at all 5 clients. The front-ends had been closed on all 5 clients. We do not have a user called 'Admin'.
Because my issue occurs for all clients, it might be caused by some sort of programming error in the front end.
A VBA bug (implicit comparison to a control in an If .. Then construct) caused this type of behaviour but was resolved in Access 2007.
Is anyone aware of similar bugs still around, or other possible culprits for this?

 

[pondlife]

Thanks Pat, very helpful. I hadn't noticed the ULS changes.

I'm suspicious that all my users are creating permanent lockfile entries. I'll keep a watch on that. What are the usual culprits?

 

[pondlife]

... and as each user closes their front-end, their entry is removed from the lockfile of the back-end.

That's not happening in my case. I'd like it to happen (so in order to run a compact/repair on the back-end I don't have to get in 30mins earlier than everyone else to reboot the server to be able to delete the lockfile).

What are the likely causes for users' entries being maintained in the lockfile after they have closed their front-end? (Apart from the client PC crashing - my problem is occurring for all users.)

 

[gemma-the-husky]

normally when the last users leaves a dbs, access deletes the lock file.

if users are not closing the dbs normally, the lock files may not be released correctly, and may remain when no users are active.

eg a user turns off his pc without closing access. or closes access by using task manager to kill the app, if they have a problem.


if the dbs is truly in use, you will not be able to delete the ldb /laccdb file manually, and you will get a windows message saying the file is in use.

the hard part is that it's one thing knowing the dbs is in use, but another thing determining exactly who is using it!

 

[pondlife]

Thanks Dave.

What we are seeing in the back-end lock file (after every client has logged off) is effectively a persisting list of all 5 clients.

We suspect that this is not caused by the usual culprits (such as your helpful list of crashes/failure to close access before power-off/killing access from task-manager), but by some part of our code in the front-end which perhaps sets up a connection to the back-end whose closure is not updated in the back-end lock file when the front-end is closed in the normal way (like the bug mentioned in my first post).

We suspect this because the back-end lock file lists all the clients persistently, not just one or two who might have had crashes etc.

We're investigating and will report back. Meanwhile if anyone has suggestions as to where to look in the front-end code please let me know!

 

[gemma-the-husky]

Thanks Dave.

What we are seeing in the back-end lock file (after every client has logged off) is effectively a persisting list of all 5 clients.

We suspect that this is not caused by the usual culprits (such as your helpful list of crashes/failure to close access before power-off/killing access from task-manager), but by some part of our code in the front-end which perhaps sets up a connection to the back-end whose closure is not updated in the back-end lock file when the front-end is closed in the normal way (like the bug mentioned in my first post).

We suspect this because the back-end lock file lists all the clients persistently, not just one or two who might have had crashes etc.

We're investigating and will report back. Meanwhile if anyone has suggestions as to where to look in the front-end code please let me know!

the bit in bold. if you have a persistent connection, and don't close it when your last form closes (eg I open a recordset - others use a connection to a hidden form) you may find that access just will not close. and you end up having to kill access in task manager. doing that will definitely not remove the lock file in the normal way - but the session's active lock on the ldb file will be removed.

but just opening the lock file to see what it contains is not reliable. just because admin is listed there 5 times, does not mean there are 5 active connections to the back end.

As I say, just see if you can delete the lock file manually. If you can, the problem is solved. if you can't delete the file, but you are 100% sure there are no active users, and you cannot see any open session's in your administration/computer management options, then restarting the server will definitely clear any locks and let you delete the lock file - although it's a bit drastic.

 

[shadow9449]

Hi Pat

1. The other problem with the timer event is that it will cause problems for you if you are trying to update a form or other object and some other form has a timer event going. So, in the databases where I have been forced to use timer events, I make the code turn off when I am the logged in user so I don't have to remember to shut down the form manually.

Can you please elaborate on this? What do you mean by:

"it will cause problems for you if you are trying to update a form or other object and some other form has a timer event going"

At first glance, this means that if I am using an Access database and entering data into one form and there is a hidden form running a timer event (i.e. similar to what you described as "is it time yet?") then something will go wrong. What will go wrong and why? Can't the OS handle that? Am I misinterpreting what you meant?

Thank you

SHADOW

 

[shadow9449]

Data entry isn't a problem. The problem is updating any OBJECT while a timer event is running. .

Oh, so you mean designing a database object, not data entry?

That's a big difference. Thanks for the clarification.

SHADOW