-2147467259 Error Number and Company Level System Security Settings? (1 Viewer)

Chauncey7

Registered User.
Local time
Today, 04:34
Joined
Jun 28, 2012
Messages
15
Thank you in advance for the help....
I'm been getting Error Number: -2147467259, Error Description: Method 'Open' of object 'Workbooks' failed.

It happens when attempting to set a workbook variable by opening the file: Set wb = objExcel.Workbooks.Open(<File>)

It works on MS Access 2016 and 365 on multiple machines but when switching to another company's machine it errors. Is there a known issue with company level system security settings and this? I'm at a complete loss of what to do next and haven't found much information on this error number.

Thank you again!
 

Isaac

Lifelong Learner
Local time
Today, 04:34
Joined
Mar 14, 2017
Messages
8,738
A few thoughts.
1. It might be helpful (not sure in this case) to post your full code.
2. I agree, that error # does seem to present under numerous unrelated circumstances.
3. Although it is common to use Application.Workbooks.Open (with no arguments), keep in mind that there are a plethora of available options there for a reason. It's possible that in the case of the workbooks you are trying to open, one or more of those arguments would be helpful to supply. A few that come to mind to consider in your case are: ReadOnly, Password, UpdateLinks, CorruptLoad.

Another idea is to make sure your objExcel is making itself .Visible = True, and .UserControl = True. Not because I think this will solve your problem, but it MIGHT expose UI prompts resulting from any problems occurring while trying to open the workbook, which might then inform you of a root cause. After making these edits to your code, I'd Break the code immediately after the line that creates your Excel Application ... and visually check out the newly opened, visible, interface of Excel. Check for any UI messages or weirdness.

You might also make sure this is not the first time the Excel application has been opened for the client-side user and somehow getting "set up" or "start up" or 365 account-related prompts.

Lastly, if it were me I would definitely try this: Open an Excel workbook yourself. Try running a workbooks.open line of code on the target workbook. See if, hosted from a regular, open workbook controlled by you in Excel......the error becomes clearer.
 
Last edited:

Chauncey7

Registered User.
Local time
Today, 04:34
Joined
Jun 28, 2012
Messages
15
Thank you! All great suggestions. When putting the excel.visible=true we figured out it might be a timing issue. It looks like it was just the client's operating environment being too slow. We put a break point in between setting the excel object and opening the file, waited a few seconds and then it worked. Just an extremely slow machine I guess. Here is the code:
(wbImport being a class module variable and GetExcel() function returns the excel object):

Public Sub OpenWorkbook(strfiledir As String)
Dim WBArray As Variant
Dim oExcel As Object

WBArray = Split(strfiledir, "\") 'Split the file name using backslash

Set oExcel = modFunction.GetExcel(False)

oExcel.Application.Wait Time:=DateAdd("s", 5, Now())

If IsWorkBookOpen(strfiledir) = False Then
Set wbImport = oExcel.Workbooks.Open(strfiledir)
Else:
Set wbImport = oExcel.Workbooks(WBArray(UBound(WBArray)))
End If

Set oExcel = Nothing

End Sub
 

Isaac

Lifelong Learner
Local time
Today, 04:34
Joined
Mar 14, 2017
Messages
8,738
Thank you! All great suggestions. When putting the excel.visible=true we figured out it might be a timing issue. It looks like it was just the client's operating environment being too slow. We put a break point in between setting the excel object and opening the file, waited a few seconds and then it worked. Just an extremely slow machine I guess. Here is the code:
(wbImport being a class module variable and GetExcel() function returns the excel object):

Public Sub OpenWorkbook(strfiledir As String)
Dim WBArray As Variant
Dim oExcel As Object

WBArray = Split(strfiledir, "\") 'Split the file name using backslash

Set oExcel = modFunction.GetExcel(False)

oExcel.Application.Wait Time:=DateAdd("s", 5, Now())

If IsWorkBookOpen(strfiledir) = False Then
Set wbImport = oExcel.Workbooks.Open(strfiledir)
Else:
Set wbImport = oExcel.Workbooks(WBArray(UBound(WBArray)))
End If

Set oExcel = Nothing

End Sub
Interesting.
I was going to say, I've never seen code "get ahead of itself" when it comes to using CreateObject to create an Excel application, nor when using early binding New Excel.Application, it always seems to "know" when it's fully "open", and then execute the workbooks.open line.
But then I saw your GetExcel function reference - which I'm going to guess is one of those "get an open instance of Excel if there is one, else create one" functions. (Just a guess).
I've had very glitchy and intermittent success with using GetObject on Excel, Outlook, etc--so personally, I just avoid it and generally always create one.
And, not that this relates to your problem at hand, but theoretically, if you Get the client's existing already-open application instance, who knows what they've done with that application? Potentially changed all kinds of settings that you might not expect or think to code for, whereas opening a new one I think gives you at least some more expectations of defaults.
Anyway - I'm glad to hear it's working!! Good luck with the rest of your project.
 

Chauncey7

Registered User.
Local time
Today, 04:34
Joined
Jun 28, 2012
Messages
15
Interesting.
I was going to say, I've never seen code "get ahead of itself" when it comes to using CreateObject to create an Excel application, nor when using early binding New Excel.Application, it always seems to "know" when it's fully "open", and then execute the workbooks.open line.
But then I saw your GetExcel function reference - which I'm going to guess is one of those "get an open instance of Excel if there is one, else create one" functions. (Just a guess).
I've had very glitchy and intermittent success with using GetObject on Excel, Outlook, etc--so personally, I just avoid it and generally always create one.
And, not that this relates to your problem at hand, but theoretically, if you Get the client's existing already-open application instance, who knows what they've done with that application? Potentially changed all kinds of settings that you might not expect or think to code for, whereas opening a new one I think gives you at least some more expectations of defaults.
Anyway - I'm glad to hear it's working!! Good luck with the rest of your project.

Thank you!
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 06:34
Joined
Feb 28, 2001
Messages
27,001
Your error -2147467259 translates via hexadecimal to 80004005. That means this was a system error. When I look it up under that number, it tells me that there is a problem with accessing a shared drive or folder. I think that means you need to see if the wonky system has the same security settings as the other machines that behave better. I included a reference that shows that Access isn't the only app to have the problem.



 

Users who are viewing this thread

Top Bottom