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).
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada