Runtime Error 52 when using Dir Function

[willknapp]

I'm trying to delete a file in a network location. Sometimes the file is there, sometimes it's not, so I'm using the following code:

strPath = "\\network drive\My Folder\"
strFilename = "MyFile.doc"
If Not Dir(strPath & strFilename) = "" Then Kill strPath & strFilename

Occasionally, I get a runtime 52 error when the file doesn't exist. I don't understand why I'm getting this when, if the file doesn't exist, the Dir function should return "".

I searched the forums for Runtime 52, and didn't find anything pertaining to this.

Thanks in advance for any help.

Will

 

[missinglinq]

...Occasionally, I get a runtime 52 error when the file doesn't exist...

...I searched the forums for Runtime 52, and didn't find anything pertaining to this...

No idea why this is on again/off again, but Error 52 is "Bad File Name or Number."

Linq ;0)>

 

[Mihail]

If you know that
if the file doesn't exist, the Dir function should return ""

then check if is "":
If Dir(strPath & strFilename) <>"" Then Kill strPath & strFilename

or
If Not (Dir(strPath & strFilename) = 0) Then Kill strPath & strFilename

in order to negate entire expresion.

 

[willknapp]

Sorry for not being clear - I know what the error is. My question is that, if it is a bad file name, why does it cause an error rather than return an empty string?

Further, when I type the literal file path and file name into the Immediate window prompt, while the VB is in break mode, I do in fact get the empty string.

And why isn't this caught in my error handler? The If/Kill line is part of the clean up at the end of the procedure, and this error only pops up when another error has already been raised. Do I need to reset it somehow? that I'm missing?

PROC_EXIT:
    Set msgNew = Nothing
    Set rsInq = Nothing
    Set rs = Nothing
    Set db = Nothing
    If Not Dir(strPath & strFilename) = 0 Then Kill strPath & strFilename
    Call Initialize_Handler
    Exit Sub
PROC_ERR:
    Debug.Print Err.Number & ": " & Err.Description & " " & Now()
    End Select
    Err.Clear
    GoTo PROC_EXIT

 

[willknapp]

If you know that
if the file doesn't exist, the Dir function should return ""

then check if is "":
If Dir(strPath & strFilename) <>"" Then Kill strPath & strFilename

I have an old habit of trying to use "not" and "=" rather than "<>" - in this particular instance, though, it makes no difference, since either way, Dir(strPath & strFilename) returns the error regardless of how it's evaluated.

 

[willknapp]

or
If Not (Dir(strPath & strFilename) = 0) Then Kill strPath & strFilename

in order to negate entire expresion.

Mihail,

For some reason when I initially replied, this part didn't show up in your reply. Either way, the error still occurs.

 

[Mihail]

Ups. Is now when I see the last statements in your code:

PROC_ERR:
    Debug.Print Err.Number & ": " & Err.Description & " " & Now()
    End Select
    Err.Clear
    GoTo PROC_EXIT

Where the Select Case statement start ? And WHY ???? you have an End Select statement under the error handler ?
Also look at the very last statement: GoTo PROC_EXIT and where jump the code.
In other words, if an error occurred, the thread is jumping in order to rerun the code starting with PROC_EXIT label.

For me has no sense.

 

[willknapp]

For me has no sense.

I purposefully left out the major part of the function due to preprietary (and ultimately irrelevant) information. The End Select statement was left in by accident, as I had a couple of application-specific error handling procedures in place.

Here is the code:

Public Sub MySub(msgNew as outlook.mailitem, strPath as String, strFile as String)
    On Error GoTo PROC_ERR:
 
    ' Here lies a bunch of function calls, calculations and manipulations that
    ' are in no way germaine to the issue I'm having, and since much of
    ' the included information is proprietary, it made sense, to me at least,
    ' that I could leave it out so as to make the code a little easier
    ' on the eyes.
 
    ' Please note that the recordset and database objects are not 
    ' declared within the function because they are declared publicly.
 
    ' And now to begin the exit and error handling statements
 
PROC_EXIT:
    Set msgNew = Nothing
    Set rsInq = Nothing
    Set rs = Nothing
    Set db = Nothing
    If Not Dir(strPath & strFilename) = "" Then Kill strPath & strFilename
    Call Initialize_Handler
    Exit Sub
 
PROC_ERR:
    Select Case Err.Number
        Case 50000
            ' Do something that doesn't affect any of the existing variables
        Case 50001
            ' Do something else that has no effect on any of the existing
            ' variables
        Case Else
            Debug.Print Err.Number & ": " & Err.Description & " " & Now()
    End Select
    Err.Clear
    GoTo PROC_EXIT    
 
End Sub

Again, to be clear, the function works perfectly 99.7 percent of the time (literally, 997 times out of 1000 runs so far.) The other three times, for no reason in particular, I get a Runtime 52 when I get to this line:

    If Not Dir(strPath & strFilename) = "" Then Kill strPath & strFilename

that specifically refers to the Dir call.

I cannot recreate it reliably, and when I run the offending code in the Immediate window - while the VBA is in break mode - using the literal values of the variables in the code, it runs perfectly.

I have included everything relevant to the issue at hand; the strings used to make up the Dir statement are never null and are always made up of a valid combination of paths, slashes, filenames and extensions.

What's truly telling to me is the fact that I cannot recreate the problem. A string that offends the Dir statement once, will be fine the next time (as evidenced by the fact that the immediate window call works just fine).

Again, I have copied the code over and made a few edits so as not to violate my client's confidentiality, so there may be an errant bit of syntax, though I've done my best to leave in code that would run reliably if cut and pasted into an IDE.

 

[Mihail]

Ok. Now is clear. Very clear and we can stop to hunt some errors in your code.
And the last information, (99.7 % - , why not 99.71 % ) and the fact that work in Immediate window after it generates an error, allow me to think that the problem is the physical connection thru the network.
Try to use another machine (if it is possible) for that files that will be deleted.

Another idea:
When the error occur, run 2 or more times the same cod in order to delete the file.
I see that you are enough skilled to play with error events - error handler in order to do that.

All this are only suggestions. Sorry but I have no more ideas.

Good luck ! (I think that you really need)

 

[willknapp]

WORKAROUND - Runtime Error 52 when using Dir Function

I've developed the following workaround which simply ignores any errors raised when deleting the file. I changed

PROC_EXIT:
    Set msgNew = Nothing
    Set rsInq = Nothing
    Set rs = Nothing
    Set db = Nothing
    If Dir(strPath & strFile) = "" Then Kill strPath & strFile
    Call Initialize_Handler
    Exit Sub

to:

PROC_EXIT:
    Set msgNew = Nothing
    Set rsInq = Nothing
    Set rs = Nothing
    Set db = Nothing
    On Error Resume Next
    Kill strPath & strFilename
    On Error GoTo 0
    Call Initialize_Handler
    Exit Sub

So far, I haven't had any exceptions. It doesn't explain why that Error 52 comes up (which seems to only come from the Dir function), but it at least accounts for it, and that makes me happy enough.

 

[spikepl]

This is a kludge. Instead of aritficailly making my self happy (an image of the three monkeys springs to mind) I'd make the error handler spit out ALL relevant data if the error occurs and identify the reason. Once I know the reason, first then I would decide whether or not to ignore it.

 

[ChrisO]

Willknapp.

There are errors in your posted code:-
Post #8.
strFile is passed in but you are testing for strFilename.

Post #8
If Not Dir(strPath & strFilename) = "" Then Kill strPath & strFilename
(You say: that specifically refers to the Dir call. But how do you know that it doesn’t refer to the Kill statement?)

Post #10.
If Dir(strPath & strFile) = "" Then Kill strPath & strFile
(If the file does not exist then Kill it???)

Post #10
On Error Resume Next
Kill strPath & strFilename
(That is not likely to raise an error but will it delete the file 1000 times in 1000?)


Given that there are errors in the code as posted, could it be the error number was in fact error 70, permission denied. Maybe the file did exist but was open at the time???

Let’s try to remove everything not required so we can test the actual requirement:-

Option Compare Database
Option Explicit


Sub TestIt()
    Dim lngCount As Long
    
    For lngCount = 1 To 100000
        MySub "C:\My Folder\", "MyFile.doc"
    Next lngCount
    
    MsgBox "Done"

End Sub


Public Sub MySub(strPath As String, strFilename As String)
    
    On Error GoTo 0
    
    If Not Dir(strPath & strFilename) = "" Then Kill strPath & strFilename
 
End Sub

Use that to test it anyway you can to try and reproduce the error.

If you can reproduce the error then the error should be obvious. If you can’t reproduce the error then shift the directory to the network drive and test again.

If you can reproduce the error then the error should be obvious. If you can’t reproduce the error then increase the loop count to 1 million.

In other words, start small and try to build up to the error.

Chris.