I did following: A database connection over vba in excel (DAO) works both in office 356 and 2016. After setting a database password in Office 356 this db cannot be opened over DAO in Office 2016. (both same lib, Office Access 16 database engine object". So I set the password in Office 16, works now. After opening the file in Excel 356 again Excel crashes at an unexpected operation without error message. Now all other DAO connections in all files on this pc do not work anymore. (I think its just a random bug and hasn't anything to do with this password thing)
This error is actually reproducible on this pc.
I created a test.accdb and added one table with 2 fields and one record.
I created a test.xlsm and added following code:
Sub Test()
Dim db As DAO.Database
Set db = DAO.OpenDatabase(ActiveWorkbook.Path & "/test.accdb")
Dim ts As DAO.Recordset
Set ts = db.OpenRecordset("SELECT * FROM Tabelle1")
Dim myfield As DAO.field
If Not ts.EOF Then
For Each myfield In ts.Fields ' crash here
MsgBox myfield.Name
Next
End If
ts.Close
db.Close
End Sub
At exactly this line excel stops existing. Just press F8(next line) and back to desktop. Just away. No error. ts.Fields is not nothing as you can see in image.
I've restarted my system, no change. How to repair DAO database connections? Or is some problem in this code? The same files work like expected on my other pc.
EDIT: As noted correclty it is not wise to call the object "field" as Excel imports the namespace of DAO automatically. The error also occurs when naming it myfield.
EDIT2: The error found in system protocol is somehow unspecific: ACEDAO.DLL 0xc0000005
Thanks for your help. It was an MS Office error which was resolved after office reinstall.
Related
I have an Excel sheet that connects to a Basis database using an ODBC connection. It worked fine when we were running Excel 2010 on Windows Server 2008, but then we upgraded to Excel 2016 on Windows Server 2016, and it doesn't work anymore.
Here's some code that demonstrates the problem:
Public Sub cnntest()
Dim cnn As ADODB.Connection
Dim sql As String
Dim rs As ADODB.Recordset
Set cnn = New ADODB.Connection
cnn.Open "DSN=redacted;UID=redacted;PWD=redacted;"
sql = "SELECT ITEM FROM IC_ITM_MST WHERE ITEM = '1400-4'"
Set rs = New ADODB.Recordset
rs.CursorLocation = adUseServer
rs.Open sql, cnn
For Each a In rs.Fields
Debug.Print a.Name
Next a
Debug.Print rs.EOF
rs.Close
cnn.Close
End Sub
When I run the above code, it prints the name of the field, so I know that it's connecting to the database and executing the query. However, when it tries to evaluate rs.EOF, it immediately crashes and throws up an error message saying "Microsoft Excel has stopped working." It also does this when I mouse over that part of the code. The exact same code runs fine when I try it on Excel 2010 on Windows Server 2008.
Any idea why it works on the old version of Excel but not the new one? Any ideas on how to fix it?
Four months later, I finally found the answer. I used the Windows event viewer to look at the error logs for the crashes, which said
"Faulting application name: EXCEL.EXE, version 16.0.4266.1001, time
stamp: 0x55ba1551
Faulting module name: BBjODBC.dll, version 14.1.1.0, time stamp: 0x5400df87
Exception code: 0xc0000005
This confirmed that the problem was with the BBj driver. It turns out that the person responsible for updating that driver had updated it on all of the server's hard drives except for the C drive, which was the one that Excel decided to use. As a result, we were stuck using a five year old version of the driver even though our tech people claimed everything was up to date. We're currently waiting for the driver to be updated, so hopefully that will fix the issue.
I have come across a strange behavior in Excel VBA when creating objects using late binding.
System information:
Windows 10 Enterprise Version: 1803
Office 365 MSO (16.0.11126.20192)32 bit
Problem description:
I have an empty Excel sheet with a macro:
Option Explicit
Sub test()
Dim ob As Object
Set ob = CreateObject("Scripting.Dictionary")
End Sub
Running this macro gives me
Run time error '429': ActiveX component can't create object
Depending on the folder where I store the macro enabled Excel file.
Folders where I can run the macro without errors
my one drive folder: C:\Users\myusername\OneDrive - MY Company Name\
all the subfolders inside this one.
Folders where errors occurs
C:\Users\myusername\
C:\Users\myusername\Desktop\
Shared network location ex: \xpto\xpto1\
C:\Temp\
C:\Q\ folder I created where I tried to mimic the same access rights as in the OneDrive folder where the macro works.
If I use early binding with the correct references the problem is not there anymore!
I tried following some steps in: https://support.microsoft.com/en-ca/help/828550/you-receive-run-time-error-429-when-you-automate-office-applications.
I have an Excel Macro Workbook (binary extension) that suddenly has developed 2 issues occasionally (sometimes it runs fine).
#1 Issue - Occasionally there is an error on Line 5
It appears the connection does not open. We get the error:
Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key Temporary (volatile) Ace DSN for process 0x7f8 Thread 0x1174 DBC
#2 Issue - Occasionally there is an error on Line 7
It appears the SQL can not run. It indicates the Worksheet tab can not be found even though it does exist. Note for this error we have no issue with Line 5 (Open Connection). The error that displays is:
[Microsoft][ODBC Excel Driver] The microsoft jet database engine could not find the object 'Worksheet Name'. Make sure the object exists...
For Issue #2 once we close the error dialog box and THE MACRO GETS DELETED !!!
Notes
The code module has not been changed in years Some days we get no errors/issues
This issue occurs for multiple Excel workbooks run by multiple people that run different VBA code blocks. However 1 of the code blocks is the same across all these macros which is the code snippet above.
The source data has not changed in years in terms of formatting or volume.
All these workbooks are on a Network server.
We are on Windows7/Excel 2010/ODBC Excel Driver (xls xlsx xlsm xlsb)
14.00.7180.5000
Code Snippet
1-Set adoConn = Nothing
2-Set adoRS = Nothing
3-Application.EnableCancelKey = xldisabled
4-strConn = "Driver={Microsoft Excel Driver (*.xls,*.xlsx,*.xlsm,*.xlsb)};DriverId=1046;Dbq=" & strFileName & ";IMEX=1;"
5-Set adoConn = New ADODB.Connection: adoConn.Open strConn
6-Application.EnableCancelKey = xlInterrupt
7-Set adoRS = New ADODB.Recordset:adoRS.Open Source:=strSQL,ActiveConnection:=adoConn
I'm curious as to why you're using ODBC to connect Excel to another Excel file, as opposed as to linking the data directly.
Intermittent connection problems point to a network issue. I would suggest removing and re-creating the ODBC connection, but I'd first want to confirm the value of strFileName as referred to in the connection string. Is it an actual server on your internal network, or an external source? (ie, is it a UNC path?)
An intermittent Unable to open registry key error likely sounds worse than it is; when having connection problems, Windows & Excel will easily get confused as to what the real problem is.
It sounds like your setup has been in place, possibly un-maintained, for a long time. When is the last time the client and server were rebooted? (Should be nightly.) Defrag, disk cleanup, etc?
As for the issue of the macro "getting deleted" when you close an error dialog, I'd need to see proof of that. I think you're misunderstanding something, unless you're re-writing the macro from scratch each time this happens..
If I Run
Sub test()
Dim Template_Excel_Instance As excel.application
Set Template_Excel_Instance = CreateObject("excel.application")
End Sub
my code breaks with an error "Automation Error, Library not registered"
If I run
Sub test()
Dim Template_Excel_Instance As object
Set Template_Excel_Instance = CreateObject("excel.application")
End Sub
It runs fine. Is there any way to fix this? Reason I ask is that this issue only affects one PC, despite having the same references as all other PCs. The first error is not coming up anywhere else
Does that PC have a different version of Excel?
The problem is with As Excel.Application. If you don't have the appropriate reference defined, then the VBA compiler will not recognise the type. Yes, VBA does have a compilation step. If you do have the reference defined, then this is sensitive to the application version (just the major part of the application version I think), so is therefore inherently non-portable.
In your latter example, you are using late binding, so only COM object registration is required, not any specific library to be added to your project. For portability, this is the way to go.
Firstly, have you tried repairing the install?
Secondly, is there a reason you are instantiating a second instance of Excel?
Thirdly, let's get a grip on what is happening, please run this code and report back.
Option Explicit
Sub TestWhatVersionDoesCreateObjectReturn()
Dim obj As Object
Set obj = CreateObject("Excel.Application")
Debug.Print obj.Version
End Sub
Sub TestWhatOtherVersionsAreCreatable()
Dim lLoop As Long
For lLoop = 7 To 16
Dim obj As Object
Set obj = Nothing
On Error Resume Next '///set break on unhadnled errors
Set obj = CreateObject("Excel.Application." & CStr(lLoop))
On Error GoTo 0
If Not obj Is Nothing Then Debug.Print obj.Version
Next
End Sub
Also, look for multiple installations of Excel. The code at this blog page will read your registry and write the results to an Excel worksheet. You say you have repaired the install but there might be other Excel installations interfering. The code in that blog will highlight multiple Excel installs.
Ok, from your feedback you say all the Excel libraries version return 14, implying no multi version installs. Hmmm, we ought to consider that actually the library that error is complaining about isn't Excel but a dependency.
Other possible leads
Social MSDN - automation error. Library not registered - solved by cleaning registry of legacy "Microsoft.Office.Interop.Excel" keys
Although I've been working with VBA for Excel for quite a long time, I've one problem I cannot solve by myself. I've described it below, hope to get some help or advice.
I'm using Excel 2007 and Windows XP, all updated with newest patches.
I'm very often using following code to get data from another workbook:
Set conn = New ADODB.Connection
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=g:\source.xls;Extended Properties=Excel 8.0;"
Sql = "SELECT Field1, Field2 FROM [Sheet1$]"
Set rst = New ADODB.Recordset
rst.Open Sql, conn, adOpenForwardOnly
Worksheets("Results").Range("A2").CopyFromRecordset rst
rst.Close
Set rst = Nothing
conn.Close
Set conn = Nothing
As simply as can be - just connect to file and get some data from it. It's working perfect as long, as the source file that is located on a common network drive (g:\source.xls) is not opened on another computer.
When some user on another computer has opened the file and I try to execute the following code, I notice one thing that I'd like to get rid off: the source Excel file is opened (in a read-only mode) on my computer and it's not closed after the connection to that file has been closed. What's worse, even if I close this source file manually, it leaves some garbage in my file, like it was never closed: see the picture after couple of code execution (the source files has been closed before):
I started to believe it's a bug that cannot be solved - hope I'm wrong :)
Your Excel version is 2007 or later?
if is use Microsoft.ACE.OLEDB.12.0 at provider and your problem is solved.
[]´s
This is actually a known bug, see: http://support.microsoft.com/default.aspx?scid=kb;en-us;319998&Product=xlw. Querying an open Excel workbook with VBA causes a memory leak to occur as the reference is not released even when closing the connection and clearing the object.
You would be much better to open your Excel data source using the built in Excel reference, rather than an ADO connection e.g:
Dim xlApp As New Excel.Application
Dim xlWrkBk As Excel.WorkBook
xlApp.WorkBooks.Open FILENAME
Set xlWrkBk = xlApp.ActiveWorkbook
And then go from here instead