none
Office 2019 Connection String RRS feed

  • Question

  • Hi,

    Office 2010, 2013 & 2016 were using almost same string:

    Provider=Microsoft.ACE.OLEDB.12.0/15.0/16.0;Data Source=x;Jet OLEDB:Database Password = x

    To check installation:

    CommonProgramFiles \ \Microsoft Shared\OFFICE14/15/16\ACECORE.DLL

    Office 2019 destroyed the order and Acecore.dll among other files are moved to:

    C:\Program Files\Microsoft Office\root\vfs\ProgramFilesCommonX64\Microsoft Shared\OFFICE16

    What kind of developer can switch to such a ridiculous path?

    It seems to be another masterpiece from new Genius Indian developers/owners of MS!

    BTW, is there a connection string for Office 2019 so we can use in our .NET app to work with Access database files?

    Thanks...

    • Edited by OSVBNET Thursday, April 4, 2019 5:18 AM
    Thursday, April 4, 2019 12:04 AM

All replies

  • Ignoring your rant for a moment: A2019 would use the same connection string as A2016. Indeed I can create an ACCDE on A2019 that runs just fine on A2016 and A365.

    Considering your rant for a moment: some people have been pushing for more discoverability as to which features are  available with a particular installation. I would not be surprised if that would come to fruition at some point. The installation folder should not be your concern, just as much as you don't care where Notepad is installed as long as you can use it. Or can you make a case to the contrary?


    -Tom. Microsoft Access MVP

    Thursday, April 4, 2019 4:24 AM
  • Thanks for input josh!

    The installation folder is a concern since at the setup stage installer needs to check for Access Database Engine 2010/2016 or Office 2013 and now that glory path!

    In app also you use the same file check method, although there are 2/3 more options!

    Office 2016 or Access Database Engine 2016 were using:

    "Provider=Microsoft.ACE.OLEDB.16.0;Data Source=X\x.accdb;Jet OLEDB:Database Password = x"

    That is NOT working with Office 2019, as well as OLEDB.17/18/19...

    Since Windows 95/98, never such destructive or funny bugs were added to each single Windows update!

    Build 1809 was a shame and how many updates in ISO level made until it became just safe to use?

    Now, RTM means Alpha not even Beta! I'm sure I was in close contact enough to find the high level of IQ/Superstitions of those some people you mentioned :)

    • Edited by OSVBNET Thursday, April 4, 2019 5:23 AM
    Thursday, April 4, 2019 5:08 AM
  • Installers may need to know what is installed, but checking a particular path for a particular file is a poor way to do that.

    I think the problem you are describing may be that you have an application outside of Office that wants to use ACE. You think that since Access is installed, that app should be able to use it. That's not necessarily so with Office installed in a "sandbox" that outside apps have no access to. The solution is to install the ACE Redist: https://www.microsoft.com/en-us/download/details.aspx?id=54920 or perhaps a lower version as there are some limitations with installing two versions side by side, also related to bitness.


    -Tom. Microsoft Access MVP

    • Marked as answer by OSVBNET Thursday, April 4, 2019 3:36 PM
    • Unmarked as answer by OSVBNET Saturday, April 6, 2019 8:43 PM
    Thursday, April 4, 2019 1:54 PM
  • Thanks Tom,

    You're right, I am using Access Database Engine either version 2010 or 2016 and they both work, also if proper version of Office 2013 is installed, we can use ACE in our app very well, this exception just applies to Office 2019.

    That's not a problem; I just wanted to check if the same way apps were able to use ACE in the past decade is possible now with Office or Access 2019.

    So it seems it's not possible anymore, even if was possible my main usage were still ACE 2010, then 2016, then Office 2013.

    I was just going to add Office 2019 support for an extra option.

    About the way to detect that installation, one engineer at InstallShield and one at Microsoft advised me to do so, near a decade ago, although the MS one, advised 2/3 more options I selected this one, thanks for the tip though :)

    If anyone finds the correct Connection String for Office 2019 please share?
    • Edited by OSVBNET Saturday, April 6, 2019 8:46 PM
    Thursday, April 4, 2019 3:36 PM
  • I have a new Dell XPS with Windows 10.  I also had dell install office 365.  I was all excited to download Visual Studio 2019 and revamp a VS application I've been using in Windows 7 professional.

    Unfortunately, Visual Studio 2019 is unable to use access which is the DB I used in my application.  It seems that Office 365, C2R is the culprit.  Because that is installed, it prevents any previous version of access to be installed.

    Whats the solution?  Is Microsoft going to support Access in Visual Studio?  They seem to be stone walling this problem that so many people are encountering.

    I have an old version of Office 2015 which was working well enough.  I'm beginning to think it's time to uninstall Office 365, reinstall office 2015 and THEN revisit my VS application.  Heck, I hated the idea of having to pay and pay and pay for office 365 anyway.

    Has anyone been able to open, read, write to an Access DB using VS 2019 when Office 365 is also being used?

    Tuesday, December 3, 2019 3:29 AM
  • Has zero to do with VS.

    The office installs (programs) are now virtulized applications. (you can google  what this means).

    The short issue and story is simply that with Access 2019 (and 2016) CTR (click to run - which is most installations,then installing Access does not expose a registered copy of ACE).

    And no, you are not prevented from installing previous versions of office. What you can't do is mix and match  the same version of office between MSI and CTR installes. And you ALSO cannot mix and match the x32 bit versions of office with x64 - but again ONLY for the same version of office.

    Regardless, just keep in mind that CTR installs now don't registrar  and expose the ACE engine by default. (they are moving towards the day when in fact you don't even install Access - it will be a single .exe, and you not even  have to install it to run it. However, as we cross this bridge and transition to this zero installing day, we see that 2013 (and I think 2016) did install + use a virtilized app version of Office/Access, but also for  the transition did install a set of stubs that are outside of the virtilized app,and this was to facilitate external programs using ACE. But then again, if your virtilizing app's and installing a whole truck load of external dependence , then that defeats the whole goal here. 

    So, you need to install the ACE data engine (not access). So, installing ACE from here should do the trick:

    https://www.microsoft.com/en-us/download/details.aspx?id=54920

    Of course pay REALLY big attention to what bit size of office/ACE you are running. Keep in mind that if you are going to run your .net project as x64 bits, then you need/want to install the x64 ACE version from above. You also want to force your project to x64 bits. (VS  is a x32 bit program, and if you choose ANY CPU, then you get a x32 bit running program. This is fine if you using ACE x32, but if you using x64, then you MUST force your project to run as x64 bits. 

    Also, if you are using x64 ACE + x64 net? Keep in mind that if you use connection builders inside of VS, they will fail. (the test connection button). This is because VS is a x32 bit program. However, when you force + run your application (even as debug),  you will get a x64 bit in-process and your connections will work - just that the test connection button will not work.

    Albert D. Kallal (Access MVP 2003-2017)

    Edmonton, Alberta Canada

    Friday, December 6, 2019 6:32 PM