2

Our application builds an Access database (.mdb) and then starts a different application with the Shell command which needs Read/Write Access to this very database. The problem is that on some systems our application seems erratically to retain an exclusive lock on the database, preventing the other application from accessing it. Only after closing down the first application can the other application proceed.

The specific Error that is raised is Error 3028, which seems to be specific for DAO 3.51 (Access '97) which we indeed employ. I cannot understand why some systems are affected (and then not consistently) and others never. I thought that it might be a timing issue and built in a Sleep period between building the database and launching the other application, but that does not help.

What is going on?

EDIT: I now created a workaround by creating the database in a separate file and then copying it. Now the second program should always be able to access it and any remaining lock problems will surface in the first program, which I maintain. I will follow up later when our users have been able to test this.

Dabblernl
  • 15,831
  • 18
  • 96
  • 148

2 Answers2

2

Are you closing the connection to the DB before passing control to another EXE?

George
  • 2,165
  • 2
  • 22
  • 34
  • No I am not. Wouldn't that just reverse the problem? The other application holding a lock on it and the first program being unable to access it? They both need Read/Write Access. Once the initial problem is solved Read and Write operations (which could be concurrent) do not cause any problems. Ever. – Dabblernl Nov 22 '12 at 22:23
  • It depends on how your application is opening it. Try adding "adModeShareDenyNone" flag when opening connection to the DB from the first app. Another issue could be your 2nd program is being opened with limited user rights... try opening it with `ShellExecute(Me.hwnd, "runas", App.Path & "Project.exe", "", App.Path, vbNormalFocus)` line (don't forget to declare ShellExecute in a module). – George Nov 26 '12 at 15:48
  • @ George I doubt that your suggestions are useful. They cover situations in which the error occurs reproducibly, not erratically. Moreover using "runas" , effecitvely running the second progam in administrator mode, seems very ugly and gives strange results in WinXP. – Dabblernl Nov 26 '12 at 18:56
  • @Dabblernl "erratically" simply means we haven't figured out the pattern yet. One of the debugging methods is a method of elimination - eliminate scenarios no matter how "ugly" or "unlikely" they are. Seeing how this issue is not resolved yet, there is a decent chance that the problem is one of those ugly and unlikely scenarios. Please let me know the results of my suggestions if you decide to try them. – George Nov 27 '12 at 15:16
0

I had a similar issue previously which wasn't quite the same but from what you have described this is the approach I would try:

Before lauching the secondary application with the shell command.

Alongside the sleep period you have already employed you will also need to close the original program which generated the .mdb file.

I achieved this by shelling a windows batch file, and then immediately exiting the original program.

Batch file makeup as follows:

ping -n 5 localhost >NUL
start MSAccess.exe "C:\DB.mdb"
exit

This allows 5 seconds for the mdb file to be freed-up before launching, you could replace my Ms Access call with your secondary program.

Matt Donnan
  • 4,933
  • 3
  • 20
  • 32