I am in the process of migrating my Access97 FE to 2003. For a while now I've been compiling both a 97 front end and a 2003 front end (97 for my XP machines, 2003 for my Win7 machines). Just recently (in the last week?).. I start losing my MSCOMCTL.OCX reference when converting. However, the odd thing is it only happens on my Windows 7 (32 bit) machine running Office 2003 (SP3). If I convert it on another Win7 64 bit, Office 2003 (SP3) machine I don't lose the referenced file.
I've registered/unregistered C:\windows\system32\mscomctl.ocx several times now (making sure to run command prompt as administrator).. and restarting. I've uninstalled Office 2003 on the troubled machine and re-loaded it to no avail. I've made sure C:\windows\system32 is in the path.. (it is)
If I compile the FE on my Win7 64-bit machine, and distribute it to this trouble machine it will not start the app properly (gets an initializing bar at the bottom) indefinitely. If I re-reference the file on the trouble machine and re-create an MDE it works on both the 32bit version and the 64 bit version of Windows 7 (even though the 64 bit has mscomctl.ocx in C:\windows\syswow64)..
Is something wrong with my Win7 32bit setup? I can take an older version of my FE (I keep a repo as I make changes) and those seem to not lose the reference. The FE in question compiles fine on my Acc97 machines and my Win7 64-bit machines. I used to compile all my 2003 FE's on the "now" troubled Win7 32bit machine... ?
I've run decompile/repair/compile/compact on the MDB file several times as well.
Can anyone suggest something to try?
UPDATE
Well I blew the "problem" workstation away and reloaded with Win7 Pro 64-bit, this will make WSUS duty easier anyway. However the problem persists... so now I'm not sure what to think.
You should confirm the version of MSCOMCTL.OCX used by your Access app is the same version used on any machine you might compile it on. Check which file the reference is using by:
Function ListReferences()
Dim a As Long
Dim b As Long
a = References.count
For b = 1 To a
Debug.Print b & ": " & References(b).Name & vbTab & vbTab & References(b).FullPath
Next b
End Function
This will give you a list of file names and paths for all references in your Access FE.
Use Windows Explorer to locate the MSCOMCTL.OCX referenced by Access. Right-click the file and note the version. Confirm the MSCOMCTL.OCX you are using on all other computers is the same version.
Maybe the MSCOMCTL.OCX on your machine was replaced by a newer version by an automatic Windows update?
At work, we had problems on some machines with this last week after the automatic installation of a certain update.
Quote from the "Known issues with this security update" section of the above link:
Windows Common Control-based embedded ActiveX controls may fail to load within pre-existing office documents, within third-party applications, and when you insert new controls in developer mode.
Apparently we were not the only ones having problems:
After installing KB2687441 Access forms utilizing components from MSCOMCTL.ocx fail to open
Related
New to the SSIS world and I got it working before on Excel Version 2016 & Version 2007-2010 [after ages of troubleshooting] but then it just stopped working [endless testing on various solutions I've read, seems to be a reoccurring issue] and now it continues to not work.... any assistance would be appreciated.
Here's the situation:
Importing Excel to the SSIS environment via VS19. when I try to view the Table in the Excel Source Editor, it comes up with the following error message:
Could not retrieve the table information for the connection manager 'Excel Connection Manager'. Failed to connect to the source using the connection manager 'Excel Connection Manager'.
Using Visual Studio Community 2019 - 16.6.30128.74
Using a 32-bit Excel from Microsoft Suite for Microsoft 365 on Windows 10 - 16.0.11929.20776
In Visual Studio Installer, I have activated the "Data storage and processing" tile with the "SQL Server Data Tools" ticked
I am running the package in 32-bit mode
Project properties >> Debugging >> Run64BitRuntime = False
I have installed both AcccessDatabaseEngine 32bit and 64bit for 2010 & 2016 on my computer
-- x64 2010 redistributable - 14.0.7015.1000
-- x32 2010 redistributable - 14.0.7015.1000
-- x64 2016 redistributable - 16.0.4519.1000
-- x32 2016 redistributable - 16.0.4519.1000
Have even done the Passive/Quiet model installation steps
Open the Command Prompt by typing cmd in the Windows search box under the Start menu and selecting cmd.exe
Type the file path and file name of the [relevant] install file, followed by a space and /passive or /quiet [if passive didn't work].
Open the Registry Editor by typing regedit in the Windows search box under the Start menu and selecting regedit.exe
Deleted the mso.dll registry value in the following registry key:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Common\FilesPaths"
[above for 2010] and [below for 2016]
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\FilesPaths"
I've tried uninstalling and reinstalling the SSDT
I've tried using all available excel version options [2007-2010, 2013, 2016] in the Excel Source Editor to no avail
I've even tried the DelayValidation method someone suggested [still didn't work]
Project Task >> Properties >> DelayValidation = True
Even checked my connection string on my Excel Connection Manager
Excel Connection Manager Connection >> Properties >> ConnectionString >> Provider=Microsoft.ACE.OLEDB.12.0
Ran a repair on both my VS19 and my Office
Made sure that all my excel files were closed
Current workaround:
I've had to save all my excel files to a .xls versions and change the config to 97-2003 in order for my SSIS to register the tables from the workbook. What am I doing wrong? Am I missing something? It was working before and now it's C#$% itself.
Can someone please suggest another solution of why I can't use my excel 2010, 2013 or 2016 version to import my Excel Source to my SSIS environment in VS19 please. Thank you.
So, I basically had to start from scratch. Wipe my laptop and reinstall everything. SSMS, VS all the add-ons, everything. Now it works perfectly, so I think it's either the sequence that I've downloaded things or something that was already in my laptop was stopping the applications from working properly. Gosh that was a nightmare. But my problem is now fixed.
From what I've seen, the problem develops almost immediately after installing Office 365. Verify you are, in fact, using 32-bit Office 365. All indications that I have encountered, Office 365 is 64-bit and the installation process REMOVES the 32-bit prior versions of Office products. And that's where the problems start.
Installing the AccessDatabaseEngine is a junkyard patch to put a 32-bit dll back into your system for Visual Studio to use when you run in 32-bit mode. It's imperfect and may not give you all the required 32-bit dlls that the newer versions of Visual Studio require, which is why results can be flaky.
The core of the problem is actually Visual Studio. The development environment EXE, even in VS 2019, is still 32-bit. Thus, when you hit F5 to run your app, the Dev Env EXE forces all dlls to use 32-bit versions. And Office 365 has forcibly removed the Excel 32-bit dlls during installation, which is why so many people do the junkyard patch (above).
If there were some way to force VS to use a 64-bit dev env EXE, then all these problems go away. But until then, you are stuck with setting all flags to use 64-bit (so you can read the most recent Excel files), deploying your code to a server that has the 64-bit dlls, then using hope-and-pray methods. You will be working mostly blind, but you should be able to get some results.
I have a Desktop: MS Office Pro Plus 2016 & Win10 Pro 64bit v1909, and also a Laptop: identical setup but different Office keys all fully activated. MS-Access has started throwing an error (exactly same on both machines) since the latest Windows update. This error is happening with a standard "Desktop Database" stand alone / not shared etc.
Whenever I try to Compact & Repair or File / Save As, MS-Access errors with-
"Could not use 'path\file.accdb'; file already in use".
This did not occur (on either machine) before the latest Windows updates. It occurs for both new DBs and existing DBs. I have tried: Permissions in the folder: I'm using an Admin Account and can read/write/update/delete etc-so no issues. I've also disabled all Firewalls, Anti Malware to see if that was the problem - same error. As the same thing has occured on 2 independent machines after the same Windows update, it makes me suspicious of that - has anyone experienced the same error or have any idea how to solve this?
Many thanks for your help in advance.
Kind regards,
Bob
I inherited a 2013 ms access db file but i do not know if the user created it with a 32- or 64-bit version of access. I know how to check my system settings to see what type my OS and MSO are, but how do I tell how a specific third-party file was created?
As far as I know, it doesn't matter. I'm pretty sure that they use the same file format.
There is an interesting article about it.
The General Rule
As a general rule, a database (in accdb file format) developed on Access x32 should run fine on Access x64 and vice versa.
When the General Rule Goes Awry
Although, a database made on Access x32 should run fine on Access x64 (and vice versa), some people report issues. You have 2 options:
Create a new blank database in the target bitness and import everything
Decompile the original database and migrate it to the other bitness and then recompile it
The article also quotes the Microsoft:
“We recommend the 32-bit version of Office for most users, because it’s more compatible with most other applications, especially third-party add-ins.” — Microsoft, see: 64-bit editions of Office 2013
If you run into the above problem, you can choose a preferred bitness (e.g. 32 bit) and for users with 64-bit Access (see the VBA code) display a warning.
If you talking about a accDB, then the creating version x32 or x64 should not matter.
However if you using a compiled accDE, then the x64 bit version of Access can ONLY open a x64 bit accDE file, and the same applies to a x32 accDE (they can only be opened with Access x32).
I don’t believe there is a “easy” way to determine if the file was created with x32 or x64 bit Access.
I have an application that uses the MS Access 2003 front end to connect to both a MS SQL and a Sybase database. This application uses VBA (Visual Basic 6) and this cannot be changed. We are in the midst of a conversion from Windows XP (where the application runs fine) to Windows 7.
On Windows 7, attempts to connect to the Sybase databsae fail. The application uses a pass through query and when the failure occurs, I receive the following message:
An unexpected error occurred in Call_SP.
Error number: 48
Error description: Error in loading DLL
Error source: Secure open security
The particular line of code where this is throwing the error is:
For Each qryDef In dbLocal.QueryDefs
The items in this line of code are defined like this:
Dim dbLocal As Database
Dim qryDef As QueryDef
Set dbLocal = CurrentDb()
When originally launching the application, there was a missing reference for Microsoft DAO 3.6 Object Library. I copied the dao360.dll file to C:\Program Files (x86)\Common Files\Microsoft Shared\DAO, registered it using regsvr32.exe, and set the reference (Tools -> References) to this file.
At this point, I suspect the problem may have something to do with user rights on this machine, but I'm stuck on where to start. Users do have "read and execute" rights on the dao360.dll file.
We have a lot of legacy apps written in Access, so our systems use Access 2003, but Word, Excel, and Outlook 2010. We are moving to Windows 7 64-bit.
If I was in your shoes, I would try the following:
Remove and re-install Access
And I would run a registry cleaner like CCleaner to remove broken library reference from the registry before re-installing Access and applying all updates.
The fact that the dao360.dll was missing or improperly registered shows that there is at least one installation issue on that machine.
Also, remove and re-install your ODBC drivers for the other databases.
Try on the same machine from a different user
Create a new user on the machine, then log under that user and check if you still get the issue.
Try from a different machine
Use the same database, make sure the DAO references are selected, and try code query again.
If it still doesn't work, then there is another issue somewhere, and it's not related necessarly to DAO.
You mention using Sybase and SQL Server.
Are the ODBC drivers functioning properly? Could there be some corruption there too on the machine?
What if you create a new database and try a single pass-through query using the same connection string?
32 and 64 bits mixup
Are you sure all dependent software and database drivers are installed for 32bit?
If you are trying to access an ODBC data source that uses a 64bit driver from a 32bit app, it will fail.
In Win7 x64 the ODBC console available from the Administrative Tools in the Control Panel is not 32bit!
You need to create your DSN using C:\Windows\SysWOW64\odbcad32.exe instead.
There is no need to attempt to re-register the dao library here and doing such is a silly wild goose chase and amounts to wasting company resources. Installing Access 2003 on that computer should work just fine and installing 2003 on that computer will ALSO correctly install the DAO libraries (attempting to copy and re-register the DAO library has the potential to turn your computer into a complete mess here – don't do this and it not required).
There are either some broken references or perhaps the ADO library was placed higher up in the references as compared to the DAO library. In fact check the references in the VBA editor. If ADO is not being used, then remove the reference.
Also if outlook is being used from this application then remove the outlook reference in this application. You REALLY need to use late binding for Outlook automation code.
I have run Access 2003 on windows 7 x64 since the win 7 beta and I had zero problems here. This is nothing to do with x64 or win7, but only that of behaviors of a typical broken reference.
The solution that I came up with was to use weak typing, and to reference all DAO objects through CurrentDb. The only references I have in my project are VBA and the Microsoft Access Object Library, which are required anyway. It is a bit radical, but it does give you something that can be deployed on any platform.
The project of every newly created Access database includes a reference to a DAO library. But DAO library references are no longer updated when databases are deployed on different machines. That feature was broken in Access 2007, when the DAO library was renamed.
In your example, this would be:
Dim qryDef As Object
For Each qryDef In CurrentDb.QueryDefs
Problem ocured when x86 and x64 version of OS/Access are instaled.
You need to create directory (I'm sure it does not exsit and You need administrative rights to do this):
C:\Program Files\Common Files\microsoft shared\DAO
Copy dao360.dll from C:\Program Files (x86)\Common Files\microsoft shared\DAO
to the directory created in step (1)
Now add reference in your VBA application.
So I have an access mdb file that was originally create using Access 2003/Office 2003. Since I have recieved a new image at work that has 2007 Office installed. The file extension of the access database is still mdb., and the convert was done to 2002-2003 Access database previously.
Here is my question: I have users that still need to access the 2003 mdb because they have not been updated yet. However, I try to compile this version, and it shows up as a .mde file (not the .accdb, etc) so it looked as though it retained the version just fine.
However when they open it, they get the standard "Cannot open file. Check to ensure that the correct version of Access is installed"
I sthere something I am doing wrong here, or forgetting to do? Once I have 2007 on my desktop can I not compile a 2003/.mde file?
Thanks
Justin
Unfortunately you can't. You have to find a 2003 machine to compile, or have a virtual machine installed with Office 2003.
You MAY however have 2 (or more) versions on a single pc, but -I think- you MUST install them in the proper order (older version first), and specify a different folder for each during the custom install.
It used to be that for the main file formats, if you compiled your MDE in the lowest version in use, it would run on the later versions. That is, for an A2000-format MDB, if you compile your MDE in A2000, it should run in A2000, A2002 (XP), A2003, and, presumably, A2007 and A2010.
If your lowest target version is A2003, then compile on A2003 and the MDE should work in A2007 and A2010 (assuming everything else is appropriately coded, e.g., late binding used wherever possible to avoid hardwired references to particular versions of Office apps, for instance).