Lock File on Back End Can this cause inconsistent file type error ? (1 Viewer)

tucker61

Registered User.
Local time
Yesterday, 16:47
Joined
Jan 13, 2008
Messages
239
Here's my setup.
I have a Front and Back End, with upto 30 users at once who copy the front end to a local drive using a bat file.
When Users log into front end the database should logs this user so i can see who is in the database.

I have just checked file explorer and can see the lock file is present, but at this time of night no one should be on the database.
So i opened the file hoping to see who was logged in, but No details are logged in the user table,
I am guessing there could be 2 things - either 1 someone did not disconnect properly and left the lock file in place, or 2 someone is linking into the back end directly (don't think it is this but it is possible).

My issue is that at 21:30 every night the back end is copied over to a local drive, compacted and repaired, and then copied back. I am guessing that during this compact and repair and copy back, if the lock file is still on the file this is causing my corruption.


What is the best way to resolve this issue.

I cant find the user, and our IT helpdesk are based in India and would not delete the lock file if requested,

I think i need to check if the lock file is present (Using a bat file), and if the file is present then do not carry out the compact and repair. - Is this the best Solution ?

Thanks in advance.
 

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 16:47
Joined
Oct 29, 2018
Messages
14,594
Hi. You said you're just guessing that the copying back the BE while there's a lock file is causing corruption, right? Why did you say that? Were you actually experiencing corruption?

The way I see it, the copy back process should fail, although I haven't tested it/this, because Windows should get an error trying to delete the BE file before you can overwrite it with the new copy.

So, that would be my guess...
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 18:47
Joined
Feb 28, 2001
Messages
19,400
Usually if you open the lock file with Windows Explorer, you see the name of the CPU. If your IT group is that widely distributed, you pretty much HAVE to be in a domain environment, so the names that appear in the lock file when viewed through Explorer WILL be the names of the workstations. That will identify the station, which should give you hints about the user. If the database isn't logging the user, there is another issue in that somehow you have a user bypassing your login method.

As to your guess regarding causes, I'm voting for your first option - failure to disconnect, properly or at all.

How you resolve this is that if everyone is using the same front-end, develop and distribute a front-end that includes some time-out code that wakes up at 21:00 and does a couple of shutdown actions.

You need to shut down all recordsets and all forms. The link will show you something about recordset collections.


You can do a FOR loop to kill all open recordsets and kill all open forms, though you should be sure to not kill the form where this code is running. Then force an Application.Quit and close the form you are in.
 

tucker61

Registered User.
Local time
Yesterday, 16:47
Joined
Jan 13, 2008
Messages
239
Update on this.

I tried opening the lock file as a txt document and got the enclosed "䍐㤷㐴䰸D†††††††††††摁業n†††††††††††††䍐㈷ㄴ䐰D†††††††††††摁業n†††††††††††††䍐㤷㜴䰰D†††††††††††摁業n†††††††††††††䍐㤷㈷䰴L†††††††††††摁業n†††††††††††††䍐㤷㔲䰳D†††††††††††摁業n†††††††††††††䍐〸㐲䰸D†††††††††††摁業n†††††††††††††䍐㌷㌱䐶D†††††††††††摁業n†††††††††††††䍐㈷ㄴ䐰D†††††††††††摁業n†††††††††††††䍐㤷㜴䰰D†††††††††††摁業n†††††††††††††䍐㘷㤵䰵L†††††††††††摁業n†††††††††††††"

So nothing that i can use to find the user.

All users copy the front end to their temp folders, so they are all using their own Front end.

I will look at closing the recordsets.

In the interim - i have created 2 batch files. 1 to check every hour to see if the lock file is still present and log this in a file (Just to see if it every disappears. and the 2nd to check if the lock file is present before updating the back end overnight. (If the lock file is present, then just take a copy of the back end and do not update).
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 18:47
Joined
Feb 28, 2001
Messages
19,400
Unless your system is set for that particular language & character set, it means you have a bad font choice for .TXT files. If you open it with a browser, you can usually see system names, at worst by changing the font you are using. You just shouldn't save the file if you change fonts.
 

tucker61

Registered User.
Local time
Yesterday, 16:47
Joined
Jan 13, 2008
Messages
239
thanks, just tried again, Opened Notepad - Font is set to Arial, then navigated to the file and opened it, it is exactly the same.
I used to be able to see PC details, but this has been like this for the last few months.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Yesterday, 18:47
Joined
Feb 28, 2001
Messages
19,400
That is a sign of corruption of some sort. You might have to create a new empty database and then try to export elements the current DB. Access should balk at any corrupted elements so that they won't transfer over.
 

Isaac

Lifelong Learner
Local time
Yesterday, 16:47
Joined
Mar 14, 2017
Messages
4,395
Just a couple thoughts to add.

First, I'm not sure that what you are seeing in the Notepad (by opening the Lock File as text) is necessarily corruption. I've certainly never tried to do that before--open a MS Access lock file as text--nor am an expert on it, but I can say that I just opened one of my Access databases, then opened the Lock file in Notepad, and I saw similar content as you did:
Code:
〱啎㔭䝃㈷㌳㉓R††††††††摁業n†††††††††††††
(and my file isn't corrupted). For me, this content was identical whether the lock file was there because I actually did have the db open, or, if the lock file was left over because I Ended Task on msaccess.exe and then checked it out.

Second, maybe you can adjust your nightly process so that it doesn't act, if, the lock file exists. However, you could also do this:
Code:
Sub Backup()
If lock file exists=false then
   do backup
else
    try to delete lock file
    if able to delete lock file then
        it's not present due to an actual current user
        do backup
    end if
end if
End Sub

I have seen cases where , let's say "external forces" kept a lock on an Office file (Access or Excel) longer than I expected. In my case it was an SSIS package that sometimes kept a lock on it long after that particular Step in the package had run and finished.
Maybe your backup process is somehow undesirably maintaining that lock.

But the test of "is this lock file exist BECAUSE someone is actually, currently using (or connecting) to the database?"...is usually going to be answered by, Can you delete the lock file. If the lock file originally came into being due to someone opening your database, and then they used Task Manager (or whatever) to end task, your lock file will still be there - BUT you'll be totally able to delete it.
 
Last edited:

tucker61

Registered User.
Local time
Yesterday, 16:47
Joined
Jan 13, 2008
Messages
239
Just a couple thoughts to add.

First, I'm not sure that what you are seeing in the Notepad (by opening the Lock File as text) is necessarily corruption. I've certainly never tried to do that before--open a MS Access lock file as text--nor am an expert on it, but I can say that I just opened one of my Access databases, then opened the Lock file in Notepad, and I saw similar content as you did:
Code:
〱啎㔭䝃㈷㌳㉓R††††††††摁業n†††††††††††††
(and my file isn't corrupted). For me, this content was identical whether the lock file was there because I actually did have the db open, or, if the lock file was left over because I Ended Task on msaccess.exe and then checked it out.

Second, maybe you can adjust your nightly process so that it doesn't act, if, the lock file exists. However, you could also do this:
Code:
Sub Backup()
If lock file exists=false then
   do backup
else
    try to delete lock file
    if able to delete lock file then
        it's not present due to an actual current user
        do backup
    end if
end if
End Sub

I have seen cases where , let's say "external forces" kept a lock on an Office file (Access or Excel) longer than I expected. In my case it was an SSIS package that sometimes kept a lock on it long after that particular Step in the package had run and finished.
Maybe your backup process is somehow undesirably maintaining that lock.

But the test of "is this lock file exist BECAUSE someone is actually, currently using (or connecting) to the database?"...is usually going to be answered by, Can you delete the lock file. If the lock file originally came into being due to someone opening your database, and then they used Task Manager (or whatever) to end task, your lock file will still be there - BUT you'll be totally able to delete it.
Thanks for this. I did create a new database and got thr same result when trying to open the lock file. So this is reassuring that it is not just me.

I have created the batch file that checks for the lock file, and I am currently running this every hour. I have never created a batch file to try and delete the file. So might try that tomorrow.

Thanks for everyone's help so far..
 

Users who are viewing this thread

Top Bottom