-2

I received this error report from a client, with a very low resolution print. I do not have direct access to the people using the excel file to ask for more details.

Run-time error '1004'

I believe the error message says:

Run-time error '1004'

Microsoft Excel cannot access the file 'C:\WINDOWS\System32'. There are several possible reasons:

  • The file name or path does not exist.
  • The file is being used by another program.
  • The workbook you are trying to save has the same name as the currently open workbook.

Maybe there is a filename after System32 but I cannot tell for sure. The line that causes the error is shown below:

Public Sub SaveButton()
    Dim file As String
    Dim answer As Integer
    Dim message As String
    Dim isXLSM As Boolean
    isXLSM = (ActiveWorkbook.FileFormat = xlOpenXMLWorkbookMacroEnabled)

    If isXLSM Then
        message = "Are you really done? If you confirm, this file will be saved without macros and it won't be possible to edit it further."
    Else
        message = "Are you really done?"
    End If
    answer = MsgBox(message, vbYesNo + vbQuestion, "Send to AskHR")


    If answer = vbYes Then
        If isXLSM Then
            Call OnClose
            file = SaveXlsx()
        Else
            ActiveWorkbook.Save 'Here is where the error ocurred
            file = ActiveWorkbook.FullName
        End If
        Call CreateEmail(file)
    End If

End Sub

My hypothesis was that maybe he was opening the file inside a zip, but I tried that and could not reproduce the error. I am not manipulating the name of the file, just returning it and using to attach to a Outlook email.

How would the file end up with this path? What could be the cause of this error?

Edit: possibly the file was opened from a read-only directory, which may have caused the error.

mathiasfk
  • 1,278
  • 1
  • 19
  • 38
  • You're going to need to do a remote debug session with your client, enter the `Debug` mode and figure out what's going on in your code. While some people here may be able to hypothesize, without actually seeing your code, or knowing anything at all about how your application is being used by the client/end-user, it's pretty much impossible to answer. – David Zemens Jul 07 '18 at 14:38
  • I was also about to say we'd need to see the code where it's breaking. If the error is continuing, perhaps easiest way is to get him on the phone, tell him to hit DEBUG at the error, hit print screen,paste into Paint, email to you, and if you can't figure it out, add it to your question.... – ashleedawg Jul 07 '18 at 14:40
  • @ashleedawg I've added the function where it's breaking. Didn't add before because I think there is nothing else relevant there except ActiveWorkbook.Save – mathiasfk Jul 07 '18 at 14:46
  • At the very least, you're going to need to figure out what the value of `ActiveWorkbook.FullName` property -- this would be the path that's raising the error. Is this ActiveWorkbook the workbook which contains the code? Or is this ActiveWorkbook a product of your code, or something that's opened/manipulated within your code? You'll also need to know the actual use-case which is causing the file to apparently exist in this System32 path. – David Zemens Jul 07 '18 at 14:47
  • 2
    On a related note, you should probably avoid relying on `ActiveWorkbook`, see: https://stackoverflow.com/questions/10714251/how-to-avoid-using-select-in-excel-vba – David Zemens Jul 07 '18 at 14:48
  • 2
    Well, the error is accurate. c:\windows\system32 is a directory, not a file. And since it is a very sensitive directory (the OS lives there), it is protected by UAC and any attempt to write or delete a file there will fail. Maybe you have to recommend them to not store their spreadsheets there. – Hans Passant Jul 07 '18 at 14:48
  • Was it trying to save with `SaveXlsx()` or with `ActiveWorkbook.Save`? My guess it it was the custom function, which had a blank filename variable, which is exactly why it couldn't save. (I think the error is accurate @HansPassant .) I'm betting `ActiveWorkbook.Save` did not generate this error. – ashleedawg Jul 07 '18 at 15:00
  • @David Zemens: Where in your linked SO Q/A is explained what else but `ActiveWorkbook` can be used if the active workbook, which is the workbook the user currently works with, is meant? In other words: There is nothing bad in using `ActiveWorkbook` because there is nothing else what could be used instead. – Axel Richter Jul 07 '18 at 15:01
  • @AxelRichter that post may not specifically call out `ActiveWorkbook`, but if it doesn't it should because conceptually it's the same issues as described in that other answer. The problem with `ActiveWorkbook` is that if you don't know *which* workbook is currently active, undesired results and errors may arise. So it is better to `Dim` a workbook variable, and use that workbook variable instead. Otherwise, the user must take great caution to ensure the correct book is active, or the code must take preventive measures to ensure same. – David Zemens Jul 07 '18 at 15:04
  • @AxelRichter the accepted answer on that post *does* mention workbooks, but I've expanded on that a bit and edited the answer. – David Zemens Jul 07 '18 at 15:14
  • @David Zemens: `ActiveWorkbook` is to be used exactly if "you don't know which workbook is currently active" because the user determines that. And yes, there are use cases for this. So: "Avoid using `ActiveWorkbook`!" is bad advise without explaining why and what should be used instead. – Axel Richter Jul 07 '18 at 15:19
  • If you don't know which workbook is active, you can use `ActiveWorkbook` reliably only if it doesn't matter which workbook is active. Since it often matters, recommend avoiding it aside from as a form of user input (i.e., assigning `ActiveWorkbook` to a `Workbook` variable. – David Zemens Jul 07 '18 at 15:21

1 Answers1

0

They're using Small Business Server 2011. They need to update their systems for full compatibility with ActiveWorkbook.

FissionChips
  • 27
  • 1
  • 6