Error 70 Permission Denied (1 Viewer)

AlanAnderson

Registered User.
Local time
Today, 03:13
Joined
Nov 27, 2012
Messages
31
Hi All,
I've just spent a few frustrating weeks trying to resolve an error that occurred when I tried to build a "Restore" programme in VBA.

I want to add that if one googles the web for Error 70 Permission Denied one finds thousands of cases and none are ever fully resolved so I think that it is worthwhile if some of the gurus out there could examine my conclusions and perhaps post something to save others from this frustration.

In my case the user (me) definitely had the correct permissions to save/delete/edit the back end database which was properly closed.

Essentially, IMHO, the problem relates to tables that are linked. When one tries to restore a file one is essentially deleting the existing file and replacing it with the backed up one. If one does this in DOS there's absolutely no problem with permissions but if one does it with VBA from within Access then Access seems to be "smart" enough to see the linking and decide that to delete a linked table is not a good idea so it stops you if you do FileCopy etc. This is even the case when it is 100% guaranteed that all files, tables, forms, queries etc are closed

The only way I've found to get around this is to run the restore programme as a separate stand alone programme and to first do the "Kill" command to entirely remove the back end. Once done then the filecopy and relinking works ok.

I suspect a better way to handle this might be to write a VBA routine that first removes all the links (and possibly the relationships) and then filecopy would probably work.

I hope this thread stimulates someone brighter than me to delve into this issue and finally resolve this issue for all time.

Regards,

Alan
 

JHB

Have been here a while
Local time
Today, 02:13
Joined
Jun 17, 2012
Messages
7,732
What type of backend database are you using, MS-Access, MS-SQL Server, …?

What file, a hole backend database, or ..?

"to run the restore programme as a separate stand alone programme", run it from where?

If it is a MS-Access backend database, do you see a lockfile (.ldb) for the backend database?
 
Last edited:

AlanAnderson

Registered User.
Local time
Today, 03:13
Joined
Nov 27, 2012
Messages
31
Hi,
Using MSAccess
Trying to replace the entire database
Running it from another MSAccess programme - BackupRestore.mdb
I don't think there was an ldb file but am not sure now.

Regards,

Alan
 

JHB

Have been here a while
Local time
Today, 02:13
Joined
Jun 17, 2012
Messages
7,732
Then check - if it is a ldb file for the backend file, then there are still open connections, and then you can't delete it.
 

JHB

Have been here a while
Local time
Today, 02:13
Joined
Jun 17, 2012
Messages
7,732
I've made a small program for you in MS-Access 2000,. Open the form "Restore Backupfile", fill the two text controls with source and destination path and file names.
 

Attachments

  • GoalWeightDBFront.mdb
    628 KB · Views: 266

AlanAnderson

Registered User.
Local time
Today, 03:13
Joined
Nov 27, 2012
Messages
31
Hi JHB,

Thanks for this. Sorry for delay but have been away. Will check it out tomorrow.

Thanks,

Alan
 

Royce

Access Developer
Local time
Yesterday, 19:13
Joined
Nov 8, 2012
Messages
99
Did you ever find a solution to this problem?

I get the same error "sometimes" for no apparent reason with a version handler that I have used for years to copy a new version of the front end from a server to the users workstations. Never have found a solution.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 01:13
Joined
Sep 12, 2006
Messages
15,656
I have struggled to see how you can rename a backend to replace the one your currently using, and have never bothered to try.

I can switch to a different backend with no problem.

What exactly are you trying to achieve by the delete/copy process?


---
to restore an old backend, I would just do it manually.

Rename the current database to mydata_yyy-mm-dd and rename the restored database to mydata.

---
in the same way, I prefer to manually manage a compact and repair of a back end, so I can take a copy of the dbs first, and I never have compact on close.
 
Last edited:

Royce

Access Developer
Local time
Yesterday, 19:13
Joined
Nov 8, 2012
Messages
99
First, you misread my post. I am copying a new version, with updates, of the front end. As for the backend, there are a lot of reasons to link to different backends. Most common one is training purposes. The second is to look at archived data "What was in this file at the end of last year?" Another is testing. Version Handlers, and relinking code has been in common use since Access 97, maybe before.

I develop access databases for many customers. When I distribute an updated package, it is placed on the server. Then an administer checks it, then "releases" it. When it is released, all the workstations using the package automatically download the new version. Customers may link to backends at different locations. The code automatically relinks to the former database. 90 % of the time the process is very clean, and very simple for the end users. BUT at some point, Windows 7 update??, I started getting occasional "Error 70" permission denied errors. I have not been able to determine why. Often all you have to do is wait awhile and it will clear up, as if something is happening in the background. But what? (I've checked all the usual suspects, the lock file, compacting on close, etc.)

I've seen the problem on developer workstations where only one person has access the file. (The server location is just a different folder on the same computer.) I have not found a solution, or a cause anywhere. The workaround seems to be "wait awhile and try again.", or have an administrator manually copy the file, neither of which is workable for me.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 01:13
Joined
Sep 12, 2006
Messages
15,656
OK. I thought this was a backend issue, not a front end issue.

1. I assume the front ends are individual per user

2. front end in use. I assume the front end is not in use and therefore you can delete mydatabase.accdb and replace it with a new database of the same name, although I do not see how you can do this when mydatabase.accdb is actually in use.

3. you might get a permission denied error if two users try to download at the same time, or if there is another network error.

4. assuming the user gets the new database, then maybe there is some network issue that prevents the backend reconnection.

I am not clear whether is issue is with problem 4, or at another step.



Personally, because of issue 2, I do some of this manually. I check versions in my front end, and refuse to open if version is incorrect. I automatically collect the new version, but leave it to users to manually fix the database name.

so given mydatabase_v1.1
if I release mydatabase_v1.2, the startup code for v1.1 informs the users they have a new version, and collects it, if it can. if not the user can collect it manually.

It then leaves it up to the user to either rename the dbs, or rename any desktop shortcut they use.
 

Royce

Access Developer
Local time
Yesterday, 19:13
Joined
Nov 8, 2012
Messages
99
... although I do not see how you can do this when mydatabase.accdb is actually in use.
It's fairly simple. The database checks the version, if a newer one is available it uses the SHELL command to start another App and uses Application.quit to shut itself down.

The second App asks the user what they want to do. The first app will have completed it's shut down by the time they see and answer the question. At least it should, I do some simple checks, like waiting till the lock file is gone. Then I rename the old file to *.bak, and copy the new one using the passed command args.

When the second app completes it starts the first app, then shuts itself down. Same basic code has worked for years with some minor changes. Till recently. Problems started some months ago that I have not been able to resolve. Happens on several machines, with not pattern that I can detect. Debug code has not revealed anything.
 

sneuberg

AWF VIP
Local time
Yesterday, 17:13
Joined
Oct 17, 2014
Messages
3,506
Often all you have to do is wait awhile and it will clear up, as if something is happening in the background. But what? (I've checked all the usual suspects, the lock file, compacting on close, etc.)

How long do you have to wait? Have you considered trapping the error, waiting some period of time, retry the offending code, and repeat this let's say ten times?
 

Royce

Access Developer
Local time
Yesterday, 19:13
Joined
Nov 8, 2012
Messages
99
>> How long do you have to wait? <<

Varies. I have had it take 10 trys over 10-20 minutes, and I've had it work a minute later. Though I've never know an immediate retry (5-10 seconds) to work. And I've gone for weeks and never seen the error. Then seen it multiple times in a day. Fortunately, I haven't seen it that much at customer sites. (I have one site where the backend is a Linux server. I've never heard of it there, but then the linux admin may be manually installing it and never telling me he had a problem.)

>> trapping the error <<
The error is trapped ... but I could send it into a retry loop, let it count the retries, and let it run for a day. Might learn something.
 

sneuberg

AWF VIP
Local time
Yesterday, 17:13
Joined
Oct 17, 2014
Messages
3,506
Could you post the part of the code that's causing the problem? I'd like to see if I can replicate it and see what I can figure out.
 

Royce

Access Developer
Local time
Yesterday, 19:13
Joined
Nov 8, 2012
Messages
99
Could you post the part of the code that's causing the problem? I'd like to see if I can replicate it and see what I can figure out.

following code has a few things stripped out to make it simpler. FileIsClosed() just looks to see if the lock file has gone away. the FileIsClosed() call was recently added. It did not solve anything.
Code:
Private Sub UpdateDatabase()
'---------------------------------------------------------------------------------------
' Procedure : UpdateDatabase
' Author    : Royce Fessenden
' Purpose   :
'---------------------------------------------------------------------------------------
'
    Dim fso As FileSystemObject
    Dim strArgs As String
    
    Dim strCaller As String ' The database that called the Version Handler.
    Dim strServerPath As String ' The location of the new update file to be copied
    Dim strDestPath As String ' where the file should be copied.
    Dim intPos As Integer
    Dim strCallerPath As String
    Dim strStep As String
    Dim strTemp As String
    Dim strMsg As String
    Dim lngResponse As Long
    
   On Error GoTo Proc_Err
    
    strArgs = Command() ' Expecting CurrentDb.Name and ServDir
    If strArgs = "" Then
        Me.txtProgress = "No parameters passed in."
        GoTo Proc_Exit
    End If
   
    
    strStep = "Create fso"
    Set fso = CreateObject("Scripting.FileSystemObject")
     
    intPos = InStr(1, strArgs, ";")
    strCaller = Left(strArgs, intPos - 1)
    strServerPath = Mid(strArgs, intPos + 1)
    
    ' Delete any .bak files
    intPos = InStrRev(strCaller, ".")
    
    strStep = "Checking .bak"
    strCallerPath = Left(strCaller, intPos) ' Should be full path without the extension, but include the .
    If fso.FileExists(strCallerPath & "bak") Then
        strTemp = strCallerPath & "bak"
        fso.DeleteFile strTemp, True
    End If
    
    
    ' Change caller extension to .bak
    strStep = "Changing extension"
    
    strTemp = strCallerPath & "laccdb" 
    ' strTemp is the lock file. C:\Wks\MRGProjects.laccdb
    ' strCaller would be C:\Wks\MRGProjects.accde
    ' strCallerPath is C:\WKS\MRGProjects.
    ' All Authenciated users have full control to the c:\WKS folder.
    ' Typically, but not always, the user is a local administrator, as that is the default installation for Microsoft.
    If FileIsClosed(strTemp) Then
        fso.CopyFile strCaller, strCallerPath & "bak", True ' <<<<< This line generates the error.
    Else
        strMsg = "The file " & strCaller & " appears to be still open.  " & _
            "If it is not, the file " & strTemp & " may need to be manually deleted before you continue." & _
            vbNewLine & vbNewLine & "Do you wish to continue?"
        lngResponse = MsgBox(strMsg, vbQuestion + vbYesNoCancel, "Caller Error")
        If lngResponse = vbNo Then
          ' exit, but leave the version handler open so the error log can be examined.
            GoTo Proc_Exit
        ElseIf lngResponse = vbCancel Then
            Application.Quit
        End If
    End If
 
    ' Copy New version to folder of original.
    strStep = "Copying File"
    fso.CopyFile strServerPath & fso.GetFileName(strCaller), strCaller, True
    
    MsgBox "Ready to restart with new version.", vbOKOnly, "New Version Uploaded"
    
    'Pass back "VersionUpdated" as command line argument when reopening the new version of the Caller.
    ' Everything past /cmd will be retrieved by strArgs = Command().
    ' Spaces are needed.  Could use semicolon instead of /cmd
    strStep = "Restart Caller after copy."
    AppActivate Shell("MSAccess.EXE " & strCaller & " /cmd VersionUpdated", vbNormalFocus)
        
    ' And close this database if everything is ok.
    Application.Quit
    

Proc_Exit:
   On Error Resume Next
    Set fso = Nothing
    
   Exit Sub

Proc_Err:
    MsgBox "Step: " & strStep & ">> " & Err.Description
    'LogError Err.Number, "Step: " & strStep & ">> " & Err.Description, mcModuleName, "UpdateDatabase", strStep & " - " & strArgs, 1, True
    Resume Proc_Exit


End Sub
 

sneuberg

AWF VIP
Local time
Yesterday, 17:13
Joined
Oct 17, 2014
Messages
3,506
Thanks for uploading the code. This will probably take awhile, but I'll let you know what I find one way or the other.
 

sneuberg

AWF VIP
Local time
Yesterday, 17:13
Joined
Oct 17, 2014
Messages
3,506
I had a minor problem getting this set up. My paths have spaces in them so I had to add quotes around the strCaller in the Shell function. But with that it's working like a charm and that's too bad as it's not going to help find the problem. Sorry but at least so far I can't replicate the error.

I'd really like to get this working as this would be something I like to implement in our systems. These intermittent types of problems are the worst.
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 01:13
Joined
Sep 12, 2006
Messages
15,656
given this

If FileIsClosed(strTemp) Then
fso.CopyFile strCaller, strCallerPath & "bak", True ' <<<<< This line generates the error.
the assumption can only be that
FileIsClosed(strTemp) is returning true when it is not closed, so the copy fails.

We ought to see fileisclosed()


strCallerPath = Left(strCaller, intPos) ' Should be full path without the extension, but include the .
If fso.FileExists(strCallerPath & "bak") Then
strTemp = strCallerPath & "bak"
fso.DeleteFile strTemp, True
End If
for what it's worth, I presume the paths have closing "\" characters. There aren't any in your notes (ignore this - I see you are getting the dbs name without the extension)


as an alternative to using fso, you can do the above with dir, name and kill.
something like the following should work ... the while loop should serve as a fileisclosed() test ....

Code:
 'test the existence of the ldb file
 on error goto next
 while len(dir(ldbfile))>0   'should error once the ldb file disappears.
     doevents
 wend
  
 'now the rename should succeed,
 name database as backupdatabase
 
Last edited:

sneuberg

AWF VIP
Local time
Yesterday, 17:13
Joined
Oct 17, 2014
Messages
3,506
This line

Code:
fso.CopyFile strCaller, strCallerPath & "bak", True ' <<<<< This line generates the error.

does not generate an error if the file is open. I just tried it. This Error 70 is about something else.
 

Users who are viewing this thread

Top Bottom