none
"Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert." RRS feed

  • Frage

  • Habe Win 10, Visual Studios 2017, Access 2016 (64bit)

    Ich arbeite an einem Projekt (C#, Windows Forms App) doch bekomme bei "conn.Open()" den Fehler "System.InvalidOperationException: "Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert." Habe recherchiert im Internet und habe gemerkt, dass viele in dieser Richtung ein Problem haben. Schlau wurde ich durch diese Recherche aber nicht.

    Bitte um Hilfe, wie ich dieses Problem lösen könnte.

    LG

    Freitag, 13. April 2018 17:31

Alle Antworten

  • Da Access 2016 64-Bit bereits installliert ist, ist auch der Treiber bereits registriert, allerdings in 64-bit!

    Das Problem ist nun allerdings, dass VisualStudio als 32-Bit ausgeführt wird obwohl 64-Bit-Anwendungen erstellt werden können.
    Um nun mit VisualStudio eine Access-DB aufmachen zu können, bedarf es der 32-Bit-Accesstreiber.
    Du solltest also die Redistributables der 32-Bit-Version von Access2016 installieren.

    Allerdings erlaubt der Installer dies normal so nicht.
    Man muss hier die Silent-Installation manuell aufrufen:
    AccessDatabaseEngine.exe /quiet

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


    Entscheidend, welche Treiberversion deine Anwendung benötigt, ist die Projekt-Build-Einstellung "x86" oder "x64".
    • Bearbeitet Der Suchende Freitag, 13. April 2018 18:26
    • Als Antwort vorgeschlagen Der Suchende Freitag, 13. April 2018 18:27
    Freitag, 13. April 2018 18:23
  • Sorry, aber das ist nicht die Lösung. Durch diesen unsinnigen Beitrag habe ich jetzt meine Office 2016 Installation zwerschossen und darf sie jetzt deinstallieren, weil ich Access nicht mehr zum Laufen bekomme. Herzlichen Dank auch.

    Warum ist Microsoft nicht in der Lage, einen Treiber zur Verfügung zu stellen, der nicht mit dem Office Paket verknüpft ist? Ich habe genau das selbe Problem, das oben geschildert ist. Man kann sich scheinbar nicht mehr auf Microsoft Technologie verlassen. Das Beste ist wohl, man verwendet MySQL - denn mit den MS SQL Server passieren genau die selben Probleme, wenn man 32 bit und 64 bit Versionen arbeitet. Spätestens beim Deployment auf den Server funktioniert es nicht mehr. 

    Mittwoch, 15. Mai 2019 20:12
  • Bei einer falschen Anwendung kann man sich das tatsächlich kaputtmachen. Dies ist mir auch schon passiert.
    Allerdings reichte da bei mir die Deinstallation der zusätzlichen Runtime und alles lief wieder.

    Also nochmal:

    Wenn Office Access installiert ist, so ist der Treiber bereits mit dabei.
    Aber: Bei 32-Bit nur der 32-Bit-Treiber, bei 64-Bit nur der 64-Bit-Treiber.

    Man darf also die Runtime der selben Bitness nicht noch mal installieren, da dann Access nicht mehr läuft!

    Wenn nun aber Office in 32-Bit installiert ist, man aber die 64-Bit-Runtime benötigt, kann man diesen Treiber separat installieren. Dabei muss man dann die Silent-Option bemühen, da der Installer sonst den Vorgang ablehnt wegen bereits installierter Treiber einer anderen Version.

    Dies gilt natürlich ebenso umgekehrt.
    Wenn man alles richtig macht, hat man auch die Treiber beider Bit-Versionen und Access funktioniert weiterhin.
    Man kann sich leider bei der Installation auch vertun, da beim Download die ausführbare Exe identisch benannt ist. Man sollte die dann in ...X86.Exe und ... x64.Exe umbenennen. Der Aufruf klappt trotzdem.

    Nachtrag:
    Dieser Beitrag ist nicht unsinnig, da ich dies so bei mir und ebenso auch bei meinen Kunden erfolgreich durchführe.

    • Bearbeitet Der Suchende Donnerstag, 16. Mai 2019 05:08
    • Als Antwort vorgeschlagen GottIstGut Freitag, 20. März 2020 08:51
    Donnerstag, 16. Mai 2019 04:55
  • Danke für Deine Antwort. Ich schreib mal auf, was ich bisher gemacht habe, nur dass vielleicht klar wird, wo das Problem liegen könnte (vielleicht bin ich es ja selbst):

    Ich habe schlussendlich gestern Office 365 in der 32 Bit Version gekauft und installiert. Jetzt läuft Office wieder inkl. Access.

    Ich habe eine Anwendung in C# erstellt, die einen DB OLEDB-Connector verwenden möchte, um auf eine Access Datenbank zuzugreifen, die in Access 2016 erstellt wurde:

    OleDbConnection connectiondb = new OleDbConnection(@"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=D:\User1\Dokumente\Access\TestLogger\TestLogger.accdb");

    Ich habe im VS 2017 Debug x86 eingestellt.

    Ich starte die Anwendung und erhalte den Fehler:

    System.InvalidOperationException: "Der 'Microsoft.ACE.OLEDB.12.0'-Provider ist nicht auf dem lokalen Computer registriert."

    Nach der hier stehenden Anleitung habe ich für Office 2016 die Datei AccessDatabaseEngine.exe (die 32 bit Version) herunter geladen und installiert.

    Allerdings musste ich mich zuerst mit dem Fehler rumschlagen, dass die sog. "Office 16 Click to run extensibility component 64 bit registration" die Installation verhindert. Diese habe ich dann manuell durch einen Beitrag im Internet inspiriert entfernt. Die Installation der  AccessDatabaseEngine.exe wurde dann durchgeführt und ich sehe zumindest bei ODBC, dass dort eine Version 16 für mdb / accdb nun verfügbar ist.

    Der Fehler im Debugmodus ist aber nach wie vor der selbe.

    Gestern hatte ich die 64 Bit Version installiert und da lief die C# Anwendung - aber mein Access nicht mehr (mit den oben beschriebenen Folgen).

    Die Frage ist also: wo liegt denn jetzt der Fehler? Ich habe durchgehend 32 bit - und es läuft trotzdem nicht. Woran erkenne ich überhaupt, wo dieser 'Microsoft.ACE.OLEDB.12.0'-Provider installiert ist?! 

    Donnerstag, 16. Mai 2019 12:32
  • Die Installation lässt sich nicht so an einem eindeutigen Key ermitteln.
    Per Regedit kann man nach der Zeichenfilge "OLE DB Provider" suchen.
    Der darauf folgende Eintrag "ProgId" enthält den Namen des OLEDB-Treibers.

    Ist der gesamte Eintrag in
    Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{....}
    handelt es sich um die 32-Bit-Version.

    In
    Computer\HKEY_CLASSES_ROOT\CLSID\{...}
    ist es dann die 64-Bit Version.

    Dies ist die Registruierung. Mittels der CLSID, die man dann suchen muss, findet man den Standort der dazugehörenden DLL.

    Ist Access installiert, verweist der Standort dann auf den Officepfad.
    Ist die Runtime installiert, so finden sich 32-Bit-Treiber in:
    C:\Program Files (x86)\Common Files\system\ole db
    und 64-Bit-Treiber in
    C:\Program Files\Common Files\system\ole db

    32-Bit-Programme werden automatisch in das richtige Verzeichnis geleitet.

    Nun ist es leider so, dass eben Visual-Studio eine 32-Bit-Anwendung ist und somit den 32-Bit-Treiber benötigt.
    Hast du 32-Bit-Office und deine App ist für x86 eingestellt, sollte der Treiber gefunden werden.
    Allerdings:
    Da du Access 2016 isnstalliert hast, heißt auch dein Treiber "Microsoft.ACE.OLEDB.16.0"!

    Du kannst aber die Version 12 nicht installieren, wenn du Version 2016 von Access hast.
    Schreibst du eine Anwendung allgemein für Access und weist nicht, welche Version bei deinem Kunden installiert ist, musst du die Connection halt alternativ mit den Treibernamen testen.

    Du kannst nur eine andere Version nehmen, wenn die Bitness (32/64) abweichen von deiner installierten Accessversion ist.

    • Als Antwort vorgeschlagen Raul Katos Sonntag, 19. Mai 2019 17:10
    Donnerstag, 16. Mai 2019 16:11
  • Nochmal herzlichen Dank für die ausführliche Darstellung. Leider läuft es immer noch nicht (zuletzt habe ich OLEDB.16.0 verwendet). Ich fasse zusammen:

    • Access 2016 32 bit ist installiert und läuft
    • OLE DB 12 / 15 und 16 (also alle drei!) sind unter WOW6432Node registriert - also 32 bit
    • Die Datei C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\ACEOLEDB.DLL ist vorhanden

    Seltsam ist also, dass alle drei Versionen in der Registry auftauchen.

    Office 365 bzw. 2016 32 bit ist gesetzt und kann ich von meinem Rechner nicht entfernen.

    Deine letzte Aussage, mit der abweichenden Bitness kann ich so nicht ganz nachvollziehen. Demnach hätte mein Access 2016 nicht "zerstört" werden dürfen, als ich die 2010er 64 bit installiert hatte, oder?

    Im Moment ist es eine App, die ich nur für mich privat nutze. Deshalb wäre ich schon froh, wenn ich es - mit welcher Version auch immer - zum Laufen bekomme.

    Vielleicht hast Du noch eine Idee? Ich möchte ungern den Rechner komplett neu aufsetzen.

    Noch was: ich habe mal spaßeshalber ein Datenquelle (DataSet) auf eben diese Access Datei hinzugefügt. Sie konnte ohne Probleme gelesen und das Schema angelegt werden.

    • Bearbeitet Raul Katos Freitag, 17. Mai 2019 15:05
    Freitag, 17. Mai 2019 15:01
  • Das ist immer so ein wenig problematisch mit COM (Component Object Model).
    Dass die Einträge noch da sind, liegt wie immer an der mangelhaften Deinstallation von Komponenten.
    Wenn du allerdings die CLSID mal weitersuchst, kann es sein, dass alle 3 Verweise auf dieselbe DLL verweisen.
    Das ist u.U. auch der absteigenden Kompatibilität geschuldet.
    OLEDB geht leider einen anderen Weg der Registrierung als normale COM-Komponenten.

    Besser ist es immer, die kompatiblen Kompnenten der Bitness zu installieren. Wer weiß, was Microsoft vielleicht noch an gemeinsamen Komponenten (also 32+64Bit) verwendet. Das ist alles undokumentiert.

    Deshalb lehnt der reguläre Installer die Installation ab, wenn eine andere Komponente (egal ob Version oder Bitness) auf dem System vorhanden ist.
    Dies würde den Einsatz einer 32-Bit-Software (wie leider noch meine) beim Einsatz von 64-Bit-office jedoch komplett ausschließen. Ich hatte bisher auch nur den umgekehrten Weg beim Kunden. Dieser hat 64-Bit Office und ich brauche 32-Bit Accesstreiber (die übrigens auchXLSX/CSV/TXT erst mitbringen).

    Freitag, 17. Mai 2019 16:55
  • Ok, das Problem ist behoben, wenn auch nicht gänzlich verstanden: die Ursache für die Fehlermeldung liegt scheinbar im Projekt, das ich in VS 2017 geöffnet hatte. Dieses war in einer anderen Umgebung entstanden, wo ich scheinbar eine 64 bit Konstellation hatte.

    Ich habe jetzt ein komplett neues Projekt angelegt und dort sogar "Any CPU" als Debug Option eingestellt. Damit hat es dann sofort funktioniert (Verwendung von OLEDB.16.0).

    Interessant wäre vielleicht nur noch zu wissen, wo im Projekt dieser Verweis steht. Ich habe es noch nicht weiter verfolgt, da es für mich vorerst erledigt ist und der Code prinzipiell auf meiner Maschine tut.

    Auf jeden Fall nochmals ganz herzlichen Dank für Deine Erläuterungen. Mit dem Wissen über die 32 / 64 Konstellationen kann ich jetzt umgehen. Vermutlich hätte ich nicht Office 365 abonnieren müssen, aber das ist nun jetzt so. 

    Beste Grüße Raul 

    Sonntag, 19. Mai 2019 17:10
  • Hallo : 18 Monate später habe ich das gleiche Problem. Damals 2017 habe ich von einem Kunden das Projekt für Windows Application übernommen. 

    Ab August 2020- Sept-2020 habe ich weiter Entwicklungen innerhalb dieses Projekts gemacht und habe die "OLEDB.12.0" für xls und csv Dateien zum lesen verwendet, weil der Excel-Sever, der das lesen natürlich schon immer beherrscht, nach meiner Meinung sehr langsam ist. In dieser Zeit Aug-Sept, habe ich mit "OLEDB.12.0" intensiv in VS 2017 gearbeitet. 

    Das OLEDB war sehr viel schneller als Excel-Server.

    Das Projekt hat dann geruht.  Ich habe seit der Zeit nichts mehr an diesem Projekt gemacht. Jetzt im November 2020 wollte ich das Projekt noch einmal testen. Es funktioniert nicht mehr. Ich habe wirklich das ganze Internet durchforst. 

    Jetzt bin ich am Ende bei Euch gelandet. 

    Und Du @Raul Katos mit Deinem letzten Beitrag hast mich noch einmal inspiriert. Du Hast Deine "Windows Application" neu aufgesetzt. Ich habe das nicht gemacht, weil da ein anderes Team von meinem Auftraggeber das Projekt in Zukunft betreuen wird.

    Aber:

    Ich habe für meine Recherche zwei unabhängige "Console Application" aufgesetzt. Eines ist schon 5 Jahre alt, da probiere ich alles aus, was ich in Projekten einsetzten will. Das zweite habe ich explizit nur auf OLEDB.12.0 angelegt. Da lese ich nur xls/csv Dateien und schreibe sie in eine Datatable. Die alte Console wie die Neue haben kein Problem damit, unter "OLEDB.12.0 " die Daten zu lesen und in die Datatable zu schreiben. 

    Die Fehlermeldung kommt nur in Zusammenhang mit der alten Windows Application.

    Frage an Euch:

    Muss ich da doch neu Aufsetzten, oder gibt es noch einen anderen Weg. Z.B. in Vs2019 übernehmen?

     

    Samstag, 14. November 2020 17:09
  • Ich habe es gerade noch einmal Probiert.

    Ein neues Projekt unter "Windows Application" aufgesetzt. Das gleiche noch einmal wie unter "Console Application".  Auch unter "Windows Application" funktioniert der OLEDB.12.0.

    Ich habe keine Installation, kein gar nichts sonst gemacht.

    Was mir jetzt aber angst macht: Ist!!!Das alte Projekt neu auf zu setzten. Nicht es zu tun, macht mir Angst. Sondern: was danach folgt. Ca. 3500 User verwenden die Applikationen. Ich kann meinem Projektleiter das zwar vorschlagen. 

    Hat jemand für so einen Umbruch Erfahrung? 

    Samstag, 14. November 2020 18:24
  • Wichtig zu wissen ist in diesem Zusammenhang noch folgendes:

    Mit Office 365 werden einige Standardtreiber bzg. CSV, Excel und Co. nicht mehr ausgeliefert, da durch PowerQuery (nun Bestandeil von Office 365) eigene Treiber mitgebracht werden die auch nur durch Powerquery verwendet werden können!
    Projekte mit OLEDB.12.x schlagen daher alle fehl!!!
    Die aktuellen AccessRuntime lässt sich nicht mehr installieren sobald Office365 installiert sein sollte.
    Schalter wie -Silient oder -Quiet wurden eliminiert. Dies ist unabhängig von der Bitness von Office.

    Abhilfe sorgt dafür nur noch die AccessRuntime2010-Installation, die noch parallel zu Office 365 ohne jegliche Probleme installiert werden kann.
    Man sollte sich diese noch rechtzeitig sichern, denn wer weiß, wann dieser Download nicht mehr möglich ist:

    https://www.microsoft.com/de-de/download/details.aspx?id=10910

    Man sollte sich aus Sicherheitsgründen die 32- und 64-Bit Versionen sichern um entsprechend gewappnet zu sein.

    • Als Antwort vorgeschlagen Der Suchende Samstag, 14. November 2020 18:54
    Samstag, 14. November 2020 18:52
  • Sorry, ich habe viel Staub aufgewirbelt.

    Am Ende war es nur ein Schalter!

    Die Einstellung wo es nicht funktioniert:

    Leider lässt man mir keine Hardkopies reinstellen.

    Bei den Projekt Properties--> Build gibt es eine Schalter Platform target.--> Prefer 32-bit.

    Dieser war bei mir nicht an.

    Nachdem ich diesen dann auf On eingestellt habe, hat es funktioniert.

     


    Der Schalter muss On Sein.

    Man muss schon darauf achten. Ich weiß nicht, ob ich diesen Schalter explizit mal ausgeschaltet habe.

    Auf jeden Fall funktioniert es bei mir in der Windows Anwendung.

    Viele Grüße Dableibi

    Montag, 16. November 2020 09:33
  • Der Schalter muss nicht on sein, da es für o.g. OLEDB-Treiber eben auch 64-Bit-Versionen gibt.
    Die AccessRuntime2010 gibt es eben für 32- und 64-Bit.

    Spätestens wenn bei euch Office 365 64-Bit mal installiert wird, scheitert deine Anwendung.

    Montag, 16. November 2020 09:38
  • Hast ja Recht. Aber hier im Diskusionsverlauf war es mir nicht klar wo das Problem war. Der Schalter ist auf jeden Fall wichtig zu beobachten, wie der steht. Es ist meines Erachtens nicht einleuchtend, wie die Einstellungen in VisualStudio unter Build zu sein haben. 

    Wenn man ein Projekt unter VisualStudio neu anlegt, ist der Schalter auf ON. Das gilt mindestens bei mir. Ich habe Microsoft 365 die Version 32Bit installiert. 

    Wenn ich (scheinbar) versehentlich mal den Schalter auf OFF stelle, funktioniert das OLEDB... im Visual Studio nicht mehr. 

    Aber bis jetzt halt nur das OLEDB. Bei allem Anderen habe ich noch keine Probleme festgestellt. 

    Vielleicht weißt da mehr?

    Donnerstag, 19. November 2020 07:39
  • Die Ursache ist klar:
    Visual Studio ist erst mal selber (immer noch) eine 32-Bit-Anwendung.
    Die Bit-Präferenz für neue und aktuelle Projekte ist via Konfigurationsmanager einstellbar.

    Wenn man via Visual Studio Designer Verbindungen und Framework nutzt (Entity, Querydesigner, ...) ist daher die Existenz von 32-Bit-Treibern erforderlich.
    Führt man dann das Projekt aus, wird es in einem Host-Prozess gestartet und da entscheidet die Bitness des Projekts. Daher sind hier dann u.U. eben 64-Bit-Treiber erforderlich.

    Auch später beim Deploy entscheidet das Projektattribut. Wenn hier halt 32-Bit gewählt ist, kommt 32-Bit zur Ausführung.
    Das führt u.U. dann zum Problem, wenn im Ziel die 64- statt 32-Bit-Treiber installiert sind oder man versucht auf einem Windows-Core-Server ausführen möchte, dem die 32-Bit-unterstützung komplett fehlt.

    Donnerstag, 19. November 2020 09:04
  • Danke!

    Ich habe lange danach gesucht und dank diesem Hinweis endlich lösen können: Nach der Umstellung in der Projekt-Build-Einstellung. 

    - Mein Problem: "microsoft.ace.oledb.12.0'-provider ist nicht auf dem lokalen computer registriert"

    - Die Lösung: Project >Properties >Build > prefer 32-Bit  //Hier die CheckBox auf "false" umgestellt.

    PS: Ich nutze die 64-Bit Version von Office und hatte im Laufe der Fehlersuche zusätzlich die accessdatabaseengine_X64.exe ( https://www.microsoft.com/en-us/download/details.aspx?id=54920 ) installiert.

    Dienstag, 8. Dezember 2020 17:31
  • Klar das das nichts brachte, da du ja auf 32-Bit fixiert warst;-).

    Wie gesagt, ab Office 365, ins besonders bei ClickToRun, benötigt man die Access2010-Runtime. Di klappt auch mit Windows Server 2019.

    Dienstag, 8. Dezember 2020 22:25
  • Hallo,

    ich bin echt am verzweifeln. Habe nun mehrfach Visual Studio 2017 oder 2019 deinstalliert / Installiert.

    Mehrfach in verschiedenen Einstellungen und Möglichkeiten Projekte neu erstellt. Immer wieder der gleiche Fehler: microsoft.ace.oledb.16.0 Provider nicht registriert

    Kann hier mir bitte wer eine Lösung geben ? Bitte für einen Anfänger mit Visual Studio.

    Früher viel in VB6 programmiert.

    Basis:

    Windows 10 Prof  64bit  // Office 2016 Pro 32.bit - alles läuft soweit perfekt // visual studio 2017 community

    Vielen, vielen Dank

    mfg. Günter



    • Bearbeitet Günter2965 Freitag, 29. Januar 2021 15:50
    Freitag, 29. Januar 2021 12:49
  • Warum willst du noch Access 2010 verwenden?
    Office bringt halt den oledb.16 mit.
    Problem: VS ist 32-Bit und benötigt dann 32-Bit-Treiber. Daher muss dann Offeice in 32-Bit installiert sein.
    Zur Laufzeit in 64-Bit ist dann wieder die 64-Bit-Version erforderlich.
    Beides gleichzeitig auf einem Rechner geht leider nicht.
    Freitag, 29. Januar 2021 13:35
  • Hi,

    sorry - Meldung: microsoft.ace.oledb.16.0 Provider nicht registriert

    Hab ja alles auf 32bit gesetzt - trotzdem die Meldung.

    Irgendwas passt nicht 


    • Bearbeitet Günter2965 Freitag, 29. Januar 2021 15:52
    Freitag, 29. Januar 2021 15:52
  • Hier hast du eine rege Diskussion mit der Lösung die 32/64-Bit Accessruntime passend zu installieren.
    https://stackoverflow.com/questions/40360932/microsoft-ace-oledb-16-0-provider-is-not-registered-on-the-local-machine-sys

    Wenn du Office 32bit hast, die 64-Bit-Runtime bzw. umgekehrt.
    Die "/quiet"-Option muss zwingend als Admin gemacht werden.

    Es ist allerdings mit Vorsicht zu geniessen:
    Wenn du bereits Access 2016 installiert hast, kannst du keine zusätzliche Runtime installieren oder dein Access funktioniert nicht mehr.
    Samstag, 30. Januar 2021 00:25