I'm receiving a compile error on the following line of code:
Dim oXL As Excel.Application
The code is in VB in MS Access 2007. The line above is the beginning of a segment to generate an MS Excel file. The obvious answer to me was to ensure that the "Microsoft Office 12.0 Object Library" is checked under Tools > References. I've done this but the error persists. Does Excel need to be installed side-by-side for this to work? What have I done wrong? Thanks in advance.
You need to reference Microsoft Excel 12.0 Object Library or use late binding. Late binding is almost always necessary if you will be sharing your project with users who may have different versions of Excel installed.
For late binding, you would instead do:
Dim oXL as object
Set oXL = CreateObject("Excel.Application")
Then your code should work as expected, without the need to make the reference... assuming you aren't using any other Excel specific values or objects.
Related
I have built an Access database that is shared on our company network. Most users on the network have Access 2010 installed but some have Access 2016. When the database has been opened by someone with Access 2016 and then subsequently opened by someone with Access 2010 they are getting an error message as the Microsoft Excel 16.0 Object Library is marked "Missing".
I can fix this temporarily by selecting the '14.0 library' but the error recurs as soon as it is opened in the later version again. Is there anything I can do to stop this from happening?
Thanks
You can use late binding, which helps you avoid the issue. Code with late binding works with any appropriate object library, whichever is available.
You need to change the object initializations:
Dim excelApp As Excel.Application
Set excelApp As New Excel.Application
To
Dim excelApp As Object
Set excelApp = CreateObject("Excel.Application")
Note that if you use late binding, intellisense will be unavailable. My usual practice is to develop using early binding, and change it to late binding as soon as it's finished.
Are you sharing an unsplit database or sharing the front end of a split database?
Access is inherently multi user, but one must distribute it correctly. The database must be split into 2 files (this is a feature in the ribbon) and then each user has their own front end file which links to the common single back end file.
Then there should be no changing occurring to references once they are set up for a user's environment.
I have an Access application that I share with other users. We share the database on a Sharepoint site and each check it out / download it for edits, then put it back in Sharepoint and check it back in. We do it this way because response time if we all share the same copy on a server is unacceptable, and we only need one person to have acces at any one time. That's not my problem right now.
Last week, my old PC died and I replaced it with a new one. The old PC is Windows7, 32 bit, with Office 2010. The new PC is also Windows7, but 64 bit and with Office 2013. As far as I know, I did not change the database format to a new version of Access or make any other changes. The data base still works fine on my new PC.
The VBA script integrates the data base with Excel workbooks and exports data to Excel. One reference I have selected is Microsoft Excel 15.0 Object Library - the same reference I've always used. Now, when I load the database back to the server and other users downloads it, they can open the data base but get an error that says "Searching for reference file Excel.exe", followed by “Undefined function ‘Format’ in expression”.
The other users' PCs are configured the way my old one was, and they were able to use the database with no problems before I converted to Office 13 and saved my copy back to the server.
So my questions are - what is causing this, and more importantly, what can I do to fix it?
"... reference I have selected is Microsoft Excel 15.0 Object Library ..."
That Microsoft Excel 15.0 Object Library is the version for Office 2013. With Office 2010, the version is Microsoft Excel 14.0 Object Library.
The reference was originally 14.0 when you developed and used the db in Access 2010. When opened in Access 2013, Access adjusted the reference to its available version (15.0). Unfortunately, when you try to use the db again in Access 2010, Microsoft Excel 15.0 Object Library is meaningless to that Access version, so it doesn't know to use Microsoft Excel 14.0 Object Library instead.
The fix is to remove that reference and convert your code to use late binding.
Here is a brief example of late binding, copied from Using early binding and late binding in Automation:
' Declare the object as a late-bound object
Dim oExcel As Object
Set oExcel = CreateObject("Excel.Application")
Note, if your code uses Excel named constants, you will need to substitute the constants' values for their names, or declare the constants in your code.
I haven't seen this exact question yet:
I have multiple installations of MS Office (don't ask, just need it!). Anyway, I've developed a database that will create and interact with Excel sheets and Word documents. Currently, when creating these files, I'm using something like Excel.14 or Word.14 to specify Office 2010 documents. We are upgrading to Office 2013, and though I will still have Office 2010 installed, I want VBA to point to Word.15 but I don't want to hard code it.
I don't want to edit the code each time we upgrade. Is there a way to ensure that these references will ALWAYS pick the latest version of installed software?
Thanks for the help!
...Scotty
You might be able to use late binding to achieve this. Instead of setting a Reference in the project and using...
Dim objExcel As New Excel.Application
Dim objWord As New Word.Application
...you could try omitting the project Reference and use
Dim objExcel As Object, objWord As Object
Set objExcel = CreateObject("Excel.Application")
Set objWord = CreateObject("Word.Application")
I am developing an Excel project in Access using VBA. My project is working in Access 2007, but it does not work in Access 2003. If I try to run the file, it shows the DLL error. Anyone know how to debug this error?
It's pretty difficult to know what's causing your problem without knowing what error message you are getting and where it's occurring.
My best guess says that you are have a problem with a reference. Usually the best way to fix this is to change your code to use late binding if the version of Excel will not always be the same on every machine.
Consider the following 3 examples:
'This is early binding.
Dim oXLS As Excel.Application
Set oXLS = New Excel.Application
'Create a new instance of an Excel Object using late binding
Dim oXLS As Object
Set oXLS = CreateObject("Excel.Application")
'Set your object to an instance of Excel that is already open using late binding
Dim oXLS As Object
Set oXLS = GetObject(, "Excel.Application")
It's easier to program using early binding because you can use intellisense. However, if your target machines might have differing versions of Excel you should consider using late binding in your production/deployment version for better compatibility.
This does NOT work:
Sub X()
Dim A As Access.Application
Set A = CreateObject("Access.Application")
'Do Stuff
End Sub
However, this DOES work:
Sub X()
Dim A As Object
Set A = CreateObject("Access.Application")
'Do Stuff
End Sub
I know they do virtually the same thing, but can anyone tell me how to make an access.application object? I should add that I have Crystal Reports 11 and on my last upgrade, it may have 'unregistered' some VBA DLLs.
(Update 2009-06-29)
In response to the first 2 questions, I am using MS Access VBA to control some other Access & Excel files. Since this will only ever run on my local machine, I can guarantee that Access will always be installed. I have also referenced the "Microsoft Access 11.0 Object Library" (MSACC.OLB).
I know there's ways around this, i.e. use early binding when coding, and switch to late binding when running it, I just don't understand why the early binding method doesn't work at all on my machine (Of course, the code works fine on another machine with Access).
If you are writing this in Access there is no need to do that as the Application object is already there for you. If you are writing this in Excel or Word then you need to add a reference to the Access Library. Go to Tools/References and look for Microsoft Access XX Object Library
Hello,The code that you say is not working is legal syntax. What error are you getting? When does it occur? Do you know the line of code it happens at?
Just as a side note, this is legal syntax as well: Dim accApp As Access.Application
Set accApp = New Access.Application
But to be clear, the CreateObject Syntax is legal and not the source of the problem.
Try Detect And Repair from the Help menu in MS Access. Worked perfect for me.