Office 365 Click-to-Run breaking ACEDAO

Question

We have a C++ application installed by many customers in the field. The application stopped functioning after our customers installed or got upgrades for Office 365, and we have unhappy customers. There is a tedious, manual workaround of uninstalling and then re-installing AccessRuntime 2013, but it seems that it works only temporarily, as customers reported the problem coming back in a couple of days.
We've narrowed this down to the following code, which works fine when AccessRuntime 2013 is installed and Office 365 is not installed, but crashes once installing Office 365. We've tested it with the latest version of Office 365 we had, Version 2101 Build 13628.20448 Click-to-Run; Microsoft Access for Microsoft 365 MSO (16.0.13628.20128) 32-bit

#include "pch.h"
#include <iostream>

#import <C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\OFFICE15\\ACEDAO.dll>  \
 rename( "EOF", "AdoNSEOF" )

int main()
{
 HRESULT hr = CoInitialize(NULL);
 if(FAILED(hr))
 throw _com_error(hr);

 DAO::_DBEngine* engine;
 hr = CoCreateInstance(__uuidof(DAO::DBEngine), NULL, CLSCTX_ALL, IID_IDispatch, (LPVOID*)&engine);
 if(FAILED(hr) || !engine)
   throw _com_error(hr);

  DAO::DatabasePtr pDbPtr = engine->OpenDatabase(bstr_t("TestDB.mdb"), FALSE, FALSE, bstr_t(""));

  std::cout << pDbPtr->GetName();

  pDbPtr->Close();
}

The database TestDB.mdb is just an empty one, and we've tried saving it both as Access 2000 and as Access 2002-2003, with the same result.

The problematic point is in line 18, engine->OpenDatabase.
The operation succeeds when Office 365 is not installed.
But when it is installed, it fails with the following exception:

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

To determine how we deal with this issue in our product we'd like to know if there a is plan from Microsoft to address this problem, and on what timeline.

Answer 1

Are you striclty using mdb files, or both mdb and accDB?

If you are only using mdb files, then I would suggest using JET in place of ACE.

The problem here is that hard code reference to office 15 - that's going to be a issue. if they install a new(er) version, then that later version of ACE is going to be registered on that computer.

The problem is attempting to use/have/rely on office 15 - but customers and users will frequent upgrade.

However, if you can use the JET provider, then it will be "alone" and not part of that up-grade cycle.

Even as a long time VB dev, we quite near 100% use late binding for just about any office program (say outlook). So, thus our software can survive multiple-updates and even jumps to office v-next.

But that fixed + hard code reference to 15? I just don't see how that's going to survive updates. The instant they update their office - say to 2016, then that's the version of ACE that going to get and be registered on that computer.

My best bet? If you are using mdb file formats, then stick to JET and not ACE. The JET engine is installed by default - since about windows xp or even before. And thus the upgrades to office will be continues updating ACE - and I don't think you can much win that battle of upgrades.

The only downside of using JET is that you limited to the mdb file format. But, office updates, and customers upgrading their office out of the blue would thus in most cases not mess with your current setup.

I should point out that even the .net office "inter-op" stubs and references from .net in fact use late binding, else just about every .net application that had a hard coded reference to say office 14 (2010) or office 15 (2013) would INSTANT break when customers upgrade. It is just NOT workable to be tied to a version of office for your code.

You might be able to create a "instance" of the ACE engine as opposed to a direct reference to the 15 library you are using. I done about 20 years of office development - never EVER could I get away with a hard coded reference to a given version of office. One simple upgrade - and you are in deep trouble.

Now, you could perhaps create a instance of the DAO data engine, while late binding is stated to be "oh so slow"? Once a instance of the object is created, then performance should not be different.

For ACE 2010-2016, this works as a windows script:

CreateObject("DAO.DBEngine.120")   ' so, late binding.

So the above will thus get you the data engine (sorry - don't know the equivalent in c++ to create a com object).

And if you use JET? then you COULD use a hard coded reference. But then again, by habit, I would not, and thus wind up using this:

CreateObject("DAO.DBEngine.36")   ' so, late binding.

However, if you willing to use JET? then this is quite solid:

C:\Program Files (x86)\Common Files\Microsoft Shared\DAO\dao360.dll

However, if you needing accDB support, then you stuck with ACE.

But, if only mdb? Then just avoid using ACE and go with JET.

ACE appeared in 2007, and is for accDB formats.

You not going to find a pretty solution here if you keep and have that hard coded reference to a given version of office. Be it the older VB6 days, or now .net? We late bind for most of office.

And for JET? Well, we never had a issue - since it was always installed in windows - even a blank fresh virgin install of windows has JET pre-installed. But ACE? That's too friendly and too tied to each version of office. So we late bind. (in other words, we simply never risked a hard coded reference to a given version of office).

Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada

Answer 2

@MG The are some issues when running multiple versions of Office on the same machine in these scenarios. The goal going forward is that if you have Office 365, you will no longer need any earlier version of the Access runtime, or redistributable, but the version of Ace that is included as part of Office 365 should be able to provide what you need.

Can you try uninstalling the 2013 Access runtime, doing a quick repair on Office 365, and then see if you still have issues?

Shane Groff
Access Engineering