I just received a new Dell XPS tablet with Windows 10 Pro version 1909 I have also have:
one other Windows 10 XPS tablet (last year's model)
Windows 7 Inspiron
Surface Pro Windows 10 version 1903
My Access 2007 with Word 2007 automation runs flawlessly on the other machines, but on the new machine, I am getting an error with this line:
Set objWord = New Word.Application
The error states
"Automation Error - Library not registered." Error 8002801d
There is a proper reference checked for Word Object Library 12.0 pointing to:
C:\PROGRAM FILES (x86)\Microsoft Office\Office12\MSWORD.OLB
The new machine has all the latest updates, and the Office 2007 has been installed, repaired, etc. The Database has been recompiled, repaired, compacted, etc. There seems to be no way to register a .OLB file
My database application runs fine if I take out any attempt to open a Word document, and the Word 2007 program also works fine independently. It's just the one line that's the problem: Access simply doesn't recognize Word even though there is a proper reference.
Since the application is working fine on three other computers. What am I missing? This machine is under warranty with Dell for Premium support, but I don't see how this can be a problem with the computer because it is otherwise working well.
Related
I'm using Windows 10 and Excel 2016 and I tried to install the Windows Common Controls (SP6) using the file mscomctl.ocx. It ran perfectly under Excel 2013 but not under Excel 2016. I'm looking for the ListView control which does no longer run on the new machine.
I performed the following steps:
Copy the mscomctl.ocx file from a running Windows 10 / Excel 2013 into the folder C:\Windows\SysWow64
Register the file with the cmd prompt regsvr32 C:\Windows\SysWow64\mscomctl.ocx
Referenced the mscomctl.ocx in VBA which then appeared in the list with a checked box
Checked the registry and theres only an entry for Version 2.2. Altough on the running machine I've got 2 entries: (Standard) & PrimaryInteropAssemblyName) where on the not running machine there's only the (Standard) entry.
Step No. 5 would have been adding the control to the Standard controls but None of the common controls does appear in the list.
Does anybody have experienced similar issues? If yes, could you resolve them?
Many thanks
Adrian
This is happening because mscomctl.ocx is a 32 bit only item. It will not work in 64 bit mode.
Addendum: in July 2017 Microsoft published a 64-bit version of mscomctl.ocx, thus since then it is possible to use its controls from Office 64-bit. The 64-bit version of mscomctl.ocx is also part of newer Office versions (like Office16). A good article about using mscomctl.ocx with Office 64-bit is available here.
Instead of coping the file from somewhere, you could always download them from Microsoft
Make sure the "Microsoft Windows Common Controls 6.0 (SP6)" reference does point on the SysWoW64 folder. If not Use the "Browse" button to select it.
Left click on the "Toolbox" -> "Additional Controls", make sure the "Selected Items Only" is not checked, and look for the "Microsoft ... 6.0 (SP6)" controls.
Note that you might experience issues when trying to open the resultant workbook in older versions of Windows and/or Excel.
we have a mixed environment. Some workstations have Microsoft Office 2010 installed while others have Microsoft Office 2007 installed. A lot of our in-house developed applications are referring to the Outlook 12.0 object library and the Excel 12.0 object library. In Office 2010 these are referring to the 14.0 object libraries. Is there a way when users launch an Access application that it checks which version of Office they have installed and when it detects either Office 2007 or Office 2010 so that it can programatically set the correct references to the Object Libraries?? Many thanks for any help and/or suggestions.
Set the references to use the earliest version of the reference and Ms Access will automatically upgrade the reference for later versions of Access if needed.
For example, if none of your workstations use anything less than Access 2007, you should set the reference to Excel 12.0. Any workstation using Access 2010 or 2013 will update the reference automatically for their local copy
I've had similar conflict issues between office 2010,2013 and 2016.
I think the whole point of initiating this thread is that "should" <> "does"...
Meaning that programing to the earlier version does not "always" work when the user PC is not running the exact same version of MS Office that was used during development.
I think maybe need to somehow add both object references to the compiled version and then the app can pick.
In other words, I think the development PC needs to be running both versions of Outlook.
You could also alternatively develop the app on a PC running the earlier version and then save off a copy to be compiled in a newer version of office on a different PC. You'd be basically generating versions specifically for each version of Office.
I am writing an application in VB.NET that will send emails using outlook. My problem is that I need the Office 2010 PIA to do this. The following are the steps I have already tried (I am using Visual Studio Express 2012):
Restarted the machine
Downloaded Office 2010 PIARedist and installed it
Restarted Visual Studio
Restarted the machine again
Uninstalled Office and the PIA and re-installed Office, making sure that the PIA was selected in the installation options (it was already selected by default, so presumably I installed it the first time I installed Office as well).
Restarted the machine again
Downloaded Office 2010 PIARedist and installed it again
Restarted VS
After each of these steps, the PIA is still not available in "Add Reference" in VS, nor do the files exist on my computer at all (a search for "Microsoft.Office.Interop.Outlook.dll" confirms this). I am running Windows 7 on my MacBook Pro. Does anyone know what my problem is here? This seems like a ridiculous amount of headache for such a simple feature.
PS The only reason I need the PIA is to be able to add CC recipients on the email. That's it. If anyone knows how to do that without the PIA, please let me know because I'd much rather just do that and be done with it.
PSS Both times when I installed the PIA itself, the installation ended silently (no indication of success or failure).
In case anyone stumbles on this question, I finally figured out how to add the interop. For some reason, it won't show up in the "Add References" window (maybe it's because I have VS2012 (11.0) and I'm using Office 2010...?) Anyway, I had to manually browse to it to add it. It was located in C:\Windows\assembly (all of the Office 2010 interops were in there). Also interesting was that a search of the entire C drive for 'Microsoft.Office.Interop.Outlook' or shortened versions of that string turned up absolutely no results, even though they are on the drive. One last note: although 'Microsoft Office 14.0 Object Library' shows up in the "Add References" window, adding that reference did not allow access to the interop.
I have done document imaging on windows 7 with MODI in office 2007 and it is successful. But when I install the same office 2007 with MODI onto windows server 2008, it does not work with my program anymore. it is throwing a comexception of "(0xc6c80001): Object hasn't been initialized and can't be used yet at MODI.IDocument.OCR". I did not change anything for the codes at all. Anyone has any idea?
I compiled some VB6 code on my Win7 x64 machine and the result .exe will not run correctly on any other machine.
VB6 code is just a new template .exe file with one button, a reference to "Microsoft ActiveX Data Objects 2.6 Library" and the following code in the button press event:
Dim db
Set db = New ADODB.Connection
It runs correctly on my machine, but no others (even other Win7 x64 machines) (Update: I found TWO other users where it runs and one of them is Jeff Atwood!, but most machines have the same problem)
I checked the references screen on both machines to see if a reference failed (it wouldn't compile then though and it compiles fine). Everything looks legit. On the 64 bit machines, the references go into SysWow64 instead of system32.
I've even compiled this successfully on a Vista 64 bit machine and had it run correctly. It's only the compile on the Windows 7 and then running on any other machine where the error happens.
Here are the results of running CompChecker on my box:
Registry info: ADODB.Connection has GUID HKEY_CLASSES_ROOT\CLSID{00000514-0000-0010-8000-00AA006D2EA4}
InprocServer32 is %CommonProgramFiles%\System\ado\msado15.dll
This is a Windows 7 SP1 issue. See http://support.microsoft.com/kb/2517589 for workarounds.
There are other ways around this:
Use ADO 2.8 instead (from Win 7 RTM
disk)
Use late-binding (probably the
easiest)
There are a million things that
people are trying on this very long
and angry thread: Breaking change in MDAC ADODB COM components in Windows 7 Service Pack 1
Also, another thing, msado15.dll is not supported on x64 Win 7 as listed here: http://support.microsoft.com/kb/983246. It's a big page, just search on msado15.dll.
Check out the version of the MDAC components in both machines using this tool
Also be sure that you are using the same SQL Server (guessing) version database, since I've noticed that SQL Server 2008 x64 works differents than previous versions handling connections (when using VB6)