Record Locking File wont dissappear after file shut down

[ccondran08]

I have a procedure in a database (DB1) that I want to run from a different database(DB2). The following code works fine (from DB2) but it is leaving the 'Record Locking File' open after the database (DB1) has run and wont go away. Any suggestions would be greatly appreciated :banghead:


Dim appAccess As Access.Application

' Create instance of Access Application object.
Set appAccess = CreateObject("Access.Application")

' Open WizCode database in Microsoft Access window.
appAccess.OpenCurrentDatabase "C:\My Documents\WizCode.accdb", False

' Run Sub procedure.
appAccess.Run "Import_PT"
Set appAccess = Nothing

 

[sneuberg]

You could try putting a

appAccess.CloseCurrentDatabase

before the Set appAccess = Nothing

 

[arnelgp]

also if you are running this code in access, you do not need to make another instance to open the database.

 

[MarkK]

What harm is there if the .ldb file isn't removed?

 

[ccondran08]

You could try putting a

appAccess.CloseCurrentDatabase

before the Set appAccess = Nothing

Brilliant, works perfectly.

 

[HiTechCoach]

What harm is there if the .ldb file isn't removed?

The fact that the .ldb file is still there is a HUGE RED FLAG indicating that database was not closed properly. Not something you want to see.

 

[The_Doc_Man]

Every now and then we get this one on our shared database. Almost always, it occurs because someone's application terminated incorrectly, perhaps due to either a network glitch or a power glitch that doesn't shut down the system but DOES terminate the application. The trick is to find out who has the file lock open. If that person doesn't just shut down the application but actually reboots the computer, you might then be able to delete the lock file (if nobody else is in it at the time.)

Believe it or not, logging off and logging on again DOES NOT close the lock file because what has happened is that Windows has these things called "file handles." THEY are the actual paths from application to file and THEY are the things that keep the lock file open. Because of the faulty CLOSE, the file handle is now in limbo. Opening the application again creates a NEW and different file handle, so closing the second instance of the application is too late. Sort of like closing the barn door after the horses got out.

The reason that the file handle doesn't go away is because you don't own it, you only "rent" it from SYSTEM, who actually owns all handles in system scratchpad memory. That is why it persists if you log out with it in an inconsistent state. Only a cold-iron reboot fixes this problem. This even applies for local databases on your own system if they had some network-based or power-based reason to go to sleep and didn't wake up quite right.

 

[gemma-the-husky]

you can try to delete the ldb file manually. If it is REALLY locked you won't be able to.

if you can't establish who does have the lock, one alternative is to reboot the server.

Probably sneuberg is correct, and you need to close the database in a different manner.