Der Anbieter 'Microsoft.ACE.OLEDB.12.0' ist nicht auf dem lokalen Computer registriert

Ich versuche, Daten aus einer Excel-Datei bei einem Klickereignis abzurufen. Meine Verbindungszeichenfolge lautet:

 string connString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\\source\\SiteCore65\\Individual-Data.xls;Extended Properties=Excel 8.0;";

Wenn ich auf die Schaltfläche klicke, wird folgende Fehlermeldung angezeigt:

Der Anbieter 'Microsoft.ACE.OLEDB.12.0' ist nicht auf dem lokalen Computer registriert.

Ich habe keine Ahnung, wie ich das beheben soll. Mein Betriebssystem ist Windows 7.

Nun, Sie müssen es installieren. Du schaust nach:

• Der 2007 Office System-Treiber: Datenkonnektivitätskomponenten .

Eine 64-Bit-Version von 'Microsoft Access Database Engine 2010 Redistributable', mit der Sie den Anbieter 'Microsoft.ACE.OLEDB.12.0' verwenden können, finden Sie hier:
http://www.microsoft.com/en-us/ download / details.aspx? id = 13255

Wenn Sie den Download aus der akzeptierten Antwort verwenden, müssen Sie für x86 erstellen, wie von @ backtestbroker.com hervorgehoben.

Abhängig von der App (32 / 64bit) über die Verbindung können Sie einfach installieren

• Zugriff auf 2007-Engines (nur 32 Bit)
• Access 2010 (32 & 64bit)
• Zugriff auf die volle Laufzeit 2013 (32 & 64 Bit!> 200 MB)
• Zugriff auf die Laufzeit 2016
• Zugriff auf die Laufzeit 2019

Zusammenfassung:

• Alle Büros von 2007 bis 2016 enthalten den Anbieter "Microsoft.ACE.Oledb.12.0".
• Wählen Sie abhängig von Ihrer Anwendungsarchitektur die entsprechende Laufzeit-Engine (32/64) 6

• Überprüfen Sie Ihre Provider mit dem Powershell-Befehl der 32- und 64-Bit-Shell :

  (New-Object system.data.oledb.oledbenumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION 

• und Sie werden sehen, welchen Anbieter Ihr System verwenden kann

Die lange Geschichte: Die Zeichenfolgen finden Sie unter http://live.sysinternals.com/strings.exe

z.B. auf einem 64-Bit-System mit installierten 32-Bit-Treibern

strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\MSO.DLL" | findstr "ACE.O"
strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE14\MSO.DLL" | findstr "ACE.O"
strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE15\MSO.DLL" | findstr "ACE.O"

auch im kommenden Büro 2016

c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16\MSO.DLL
c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\MSO.DLL

Sie finden die Zeichenfolgen

• Microsoft.ACE.OLEDB

• Microsoft.ACE.Oledb.12.0

Das Office 2013 wird auch mit csi.dll geliefert

c:\Program Files (x86)\Common Files\microsoft shared\OFFICE15\Csi.dll
c:\Program Files\Common Files\Microsoft Shared\OFFICE15\Csi.dll

welches die " Microsoft.ACE.OLEDB.15.0 " enthält

und Büro 2016

c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16\Csi.dll
c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\Csi.dll

welches die " Microsoft.ACE.OLEDB.16.0 " Version hat

Das erste, was Sie überprüfen müssen, ist Ihre Build-Konfiguration Ihrer Anwendung.

• Wenn Sie Ihr Projekt unter der x86-Plattform erstellt haben , sollten Sie zur Behebung Ihres Problems die folgenden Pakete auf Ihrem Computer installieren:

  1. Um den Anbieter 'Microsoft.ACE.OLEDB.12.0' verwenden zu können, müssen Sie zuerst das Microsoft Access Database Engine 2010 Redistributable installieren. Diese Installation ist verfügbar unter: http://www.microsoft.com/download/en/details.aspx id = 13255 .

     Versuchen Sie nach Abschluss der Installation, Ihre Anwendung auszuführen. Wenn das Problem dadurch behoben wird, fahren Sie mit Schritt 2 fort.

  2. Dieser nächste Schritt ist eine ungeklärte Problemumgehung, die für Office 2010 funktioniert, obwohl es sich um die Datenkonnektivitätskomponenten von Office 2007 handelt. Ich bin mir nicht ganz sicher, warum dies funktioniert, aber es funktioniert, und dies hat sich in fast allen Fällen bewährt. Sie müssen den 2007 Office System Driver: Data Connectivity Components installieren. Diese Installation ist verfügbar unter: http://www.microsoft.com/download/en/confirmation.aspx?id=23734 .

     Versuchen Sie nach Abschluss dieser Installation, Ihre Anwendung auszuführen. Dadurch sollte das Problem behoben sein.

• Wenn Sie versuchen, eine Anwendung auszuführen , die unter der x64- oder AnyCPU-Plattform erstellt wurde , würde ich empfehlen, zunächst zu überprüfen , ob sie unter der x86-Plattform wie erwartet ausgeführt wird. Falls es nicht unter dieser x86-Plattform ausgeführt wird, führen Sie die Schritte im ersten Teil aus und überprüfen Sie, ob es wie erwartet ausgeführt wird.

  Ich habe gelesen, dass die MS Access-Treiber einschließlich des OLEDB-Datenbanktreibers nur unter der x86-Plattform funktionieren und unter der x64- oder AnyCPU-Plattform nicht kompatibel sind. Dies scheint jedoch nicht wahr zu sein. Ich habe überprüft, ob meine Anwendung beim Erstellen von x86 ausgeführt wurde, und dann das Access Database Engine mithilfe des passiven Flags installiert.

  1. Laden Sie die Datei zuerst lokal herunter. Sie können die Installation hier herunterladen: http://www.microsoft.com/en-us/download/details.aspx?id=13255
  2. Installation über die Eingabeaufforderung mit dem Flag '/ passive'. Führen Sie an der Eingabeaufforderung den folgenden Befehl aus: 'AccessDatabaseEngine_x64.exe / passive'

  Nach diesen beiden Schritten konnte ich meine Anwendung ausführen, nachdem ich die x64- oder AnyCPU-Build-Konfiguration erstellt hatte. Dies schien mein Problem zu lösen.

Hinweis: Die Reihenfolge der Schritte scheint einen Unterschied zu machen. Befolgen Sie daher die entsprechenden Schritte.

Ich habe diesen Fehler / diese Ausnahme in Visual Studio 2010 erhalten, als ich meinen Build im Dialogfeld "Configuration Manager" von "x86" in "Beliebige CPU" geändert habe. Dieser OLEDB-Datenbanktreiber funktioniert meines Wissens nur in x86 und ist nicht 64-Bit-kompatibel. Das Zurücksetzen der Build-Konfiguration auf x86 löste das Problem für mich.

Ich habe die MS-Treiber installiert und es hat bei mir immer noch nicht funktioniert. Dann fand ich diesen Blog-Beitrag , der das Problem löste. Lesen Sie es dort, andernfalls verwenden Sie diese beiden Bilder (von diesem Beitrag verlinkt) als TLDR-Zusammenfassung:

Wenn Sie 64-Bit verwenden, aber auch nach der Installation von AccessDatabaseEngine immer noch Probleme haben, lesen Sie diesen Beitrag . Das Problem wurde dadurch für mich behoben.

dh Sie müssen diese AccessDatabaseEngine installieren

Für alle, die noch davon betroffen sind.

Ich habe den Fehler bekommen ...

OLEDB error "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."

... wie vom OP beschrieben, Shailesh Sahu.

Ich habe 64bit Windows 7.

Mein Problem liegt in PowerShell- Skripten, es wird jedoch eine Verbindungszeichenfolge verwendet, die dem Beitrag des OP ähnelt. Daher können meine Ergebnisse hoffentlich auf C #, PowerShell und jede andere Sprache angewendet werden, die auf dem Treiber "Microsoft.ACE.OLEDB" basiert.

Ich habe die Anweisungen in diesem MS-Forenthread befolgt: http://goo.gl/h73RmI

Ich habe zuerst versucht, die 64-Bit- Version und dann die 32-Bit- Version von AccessDatabaseEngine.exe von dieser Seite http://www.microsoft.com/en-us/download/details.aspx?id=13255 zu installieren

Aber immer noch keine Freude.

Ich habe dann den folgenden Code in PowerShell ausgeführt (von der SQL Panda-Website http://goo.gl/A3Hu96 ).

(New-Object system.data.oledb.oledbenumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION 

... was mir dieses Ergebnis gebracht hat (ich habe der Kürze halber andere Datenquellen entfernt) ...

SOURCES_NAME              SOURCES_DESCRIPTION                                                                       
------------              -------------------                                                                       
Microsoft.ACE.OLEDB.15.0  Microsoft Office 15.0 Access Database Engine OLE DB Provider

Wie Sie sehen können, habe ich Microsoft.ACE.OLEDB. 15 .0 (fünfzehn) nicht Microsoft.ACE.OLEDB. 12 .0 (zwölf)

Also habe ich meine Verbindungszeichenfolge auf 15 geändert und es hat funktioniert.

Ein kurzes PowerShell-Snippet, das zeigt, wie die Version softcodiert wird ...

$AceVersion = ((New-Object System.Data.OleDb.OleDbEnumerator).GetElements() | Where-Object { $_.SOURCES_NAME -like "Microsoft.ACE.OLEDB*" } | Sort-Object SOURCES_NAME -Descending | Select-Object -First 1 SOURCES_NAME).SOURCES_NAME

$connString = "Provider=$AceVersion;Data Source=`"$filepath`";Extended Properties=`"Excel 12.0 Xml;HDR=NO`";"

geändert, um die neueste ACE-Version auszuwählen, falls mehr als eine vorhanden ist

Hoffentlich kann jeder, der dies findet, jetzt überprüfen, welche OLEDB-Version installiert ist, und die entsprechende Versionsnummer verwenden.

Obwohl viele Antworten gegeben wurden, wurde das Problem, auf das ich gestoßen bin, noch nicht erwähnt.

• Mein Szenario: 64-Bit-Anwendung, Win10-64, Office 2007 32-Bit installiert.

• Die Installation des 32-Bit-Installationsprogramms AccessDatabaseEngine.exe, wie es von MS heruntergeladen wurde, meldet Erfolg, wird jedoch NICHT installiert, wie mit dem Powershell-Skript einer der oben genannten Veröffentlichungen hier überprüft.

• Bei der Installation des 64-Bit-Installationsprogramms AccessDatabaseEngine_X64.exe wurde eine schockierende Fehlermeldung gemeldet:

Die sehr einfache Lösung wurde hier auf einer Autodesk-Site gefunden. Fügen Sie einfach den Parameter / passive zur Befehlszeilenzeichenfolge hinzu:

AccessDatabaseEngine_X64.exe / passive

Installation erfolgreich, der OleDb-Treiber funktionierte.

Die Excel-Dateien, die ich mit OleDb verarbeite, sind vom Typ xlsx, wurden mit EPPlus 4.5 erstellt und mit Excel 2007 geändert.

Sie müssen die Lösungsplattform von "Beliebige CPU" auf "x86" oder "x64" ändern, je nach Bitness der Office-Installation.

Die Schritte sind unten angegeben:

1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Lösungsdatei:

   2. Klicken Sie auf den Configuration Manager.

   3. Klicken Sie auf die Dropdown-Liste Aktive Plattform. Wenn x86 bereits vorhanden ist, wählen Sie diese aus. Andernfalls klicken Sie auf Neu.

   4. Wählen Sie x86 oder x64 aus der neuen Plattform-Dropdown-Liste aus:

Kompilieren Sie Ihre Anwendung und führen Sie sie aus.

Wenn die installierte "AccessDatabaseEngine" immer noch nicht hilft, finden Sie unten eine Lösung:

Sie müssen die Active Solution Platform von "Beliebige CPU" auf "x86" ändern.

Der OLEDB-Anbieter ist nicht auf dem lokalen Computer registriert

Von CodeProject.com

Ich konnte dies beheben, indem ich die Schritte in diesem Artikel befolgte : http://www.mikesdotnetting.com/article/280/solved-the-microsoft-ace-oledb-12-0-provider-is-not-registered- auf der lokalen Maschine

Der entscheidende Punkt für mich war:

Beim Debuggen mit IIS

Standardmäßig verwendet Visual Studio die 32-Bit-Version. Sie können dies in Visual Studio ändern, indem Sie zu Extras »Optionen» Projekte und Lösungen »Webprojekte» Allgemein gehen und auswählen

"Verwenden Sie die 64-Bit-Version von IIS Express für Websites und Projekte."

Nachdem ich diese Option aktiviert und das Plattformziel meines Projekts wieder auf "Beliebige CPU" gesetzt hatte (ich hatte es irgendwo in der Fehlerbehebung auf x86 gesetzt), konnte ich den Fehler beheben.

Wenn Sie ein Webprojekt debuggen, stellen Sie einfach sicher, dass IIS Express abhängig von Ihren Projekteinstellungen entweder in 32 oder 64 Bit ausgeführt wird.

Gehe zu

Extras> Optionen> Projekte und Lösungen> Webprojekte

und von dort aus aktivieren (oder deaktivieren) Sie die Option "64-Bit-Version von IIS Express verwenden ...".

Überprüfen Sie zunächst, welche Version von microsoft.ace.oledb.12.0 auf Ihrem System installiert ist.

Check-in unter Pfad C: \ Programme \ Gemeinsame Dateien \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL - 64 Bit ist installiert

Checken Sie unter Pfad C ein: \ Programme (x86) \ Gemeinsame Dateien \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL --x86-Bit ist installiert

Wenn (x86) installiert ist, ändern Sie mit dem Konfigurationsmanager die Lösungsplattform in x86, für x64 in x64.

Wenn nicht verfügbar, installieren Sie über den folgenden Link

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

syp_dino,

Die für mich vorgeschlagene Lösung für den Fehler "Microsoft.ACE.OLEDB.12.0 ist nicht auf dem lokalen Computer registriert" besteht darin, die Active Solution Platform von "Beliebige CPU" in "x86" zu ändern.

Als ich diese Schritte ausführte, die Lösung neu erstellte, die EXE-Datei ergriff und sie in das Netzwerk einfügte, funktionierte auf dem Windows 7 64-Bit-Computer alles reibungslos.

Ich hatte dieses Problem beim Versuch, Daten aus einer Excel-Datei (xlsx) mit SSMS 2014 in eine SQL Server-Datenbank zu importieren.

Die Installation von 2007 Office System Driver: Data Connectivity Components hat den Trick für mich erledigt.

Ich stand vor dem gleichen Problem. Gehen Sie zu den Lösungseigenschaften und ändern Sie jede CPU auf x86. Ich denke, sie wird den Job erledigen.

Führen Sie die folgenden 2 Schritte aus: 1. In diesem Menü: Projekt -> Ihre Projekteigenschaften ... -> Erstellen: Deaktivieren Sie "32-Bit bevorzugen". 2. In connectionString: Schreiben Sie cuotes vor und nach erweiterten Eigenschaften wie folgt: Erweiterte Eigenschaften = ' Excel 12.0 Xml; HDR = JA '

                var fileName = string.Format("{0}", openFileDialog1.FileName);
            //var connectionString = string.Format("Provider=Microsoft.Jet.OLEDB.4.0; data source={0}; Extended Properties=Excel 8.0;", fileName);
            var connectionString = string.Format("Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0}; Extended Properties='Excel 12.0 Xml;HDR=YES'", fileName);
            var adapter = new OleDbDataAdapter("SELECT * FROM [Sheet1$]", connectionString);
            var ds = new DataSet();

            adapter.Fill(ds, TableNmae);

            DataTable data = ds.Tables[TableNmae];
            dg1.DataSource = data;

Diese Konfigurationen funktionierten im Januar 2020 bei meinem neuen Maschinenbau:

(Nur 1 - x64) Windows 10 x64, Office 365 x64, AccessDatabaseEngine_x64 2016 installiert mit / passive Argumentation, VStudio-Build-Einstellungen explizit auf x64 gesetzt, mit der folgenden Verbindungszeichenfolge: Provider = Microsoft.ACE.OLEDB.16.0; Datenquelle = D: ... \ MyDatabase.accdb

(2 - x64 oder x32) Windows 10 x64, Office 365 x64, AccessDatabaseEngine_x64 2016 installiert mit / passive Argument, PLUS AccessDatabaseEngine 2010 (32 Bit) installiert mit / passiven Argument, VStudio-Build-Einstellungen auf AnyCPU gesetzt, mit der folgenden Verbindungszeichenfolge: Provider = Microsoft.ACE.OLEDB.16.0; Datenquelle = D: ... \ MyDatabase.accdb

(Nur 3 - x32) Windows 10 x64, Office 365 x32, AccessDatabaseEngine 2010 (32 Bit), installiert mit / passive Argument, VStudio-Build-Einstellungen auf x86 festgelegt, mit der folgenden Verbindungszeichenfolge: Provider = Microsoft.ACE.OLEDB.12.0; Datenquelle = D: ... \ MyDatabase.accdb

FEHLERHINWEISE

Die Verwendung des ACE.OLEDB.12.0 x64-Providers in der Verbindungszeichenfolge schlug fehl, wenn nur AccessDatabaseEngine_x64 2016 wie oben in (1) installiert wurde.

Die Verwendung von AnyCPU in den Visual Studio-Build-Einstellungen ist in (1) fehlgeschlagen. Die Einstellung von x64 ist erforderlich. Möglicherweise liegt dies daran, dass AnyCPU bedeutet, dass Vstudio zur Kompilierungszeit einen x32 ACE.OLEDB.nn.0-Anbieter sehen muss.

Die x32 / passive Engine von ACE.OLEDB.12.0 2016 wurde NICHT installiert, wenn x64-Anwendungen vorhanden waren. (Das Installationsprogramm ACE.OLEDB.12.0 2010 x32 / passive hat funktioniert.)

SCHLUSSFOLGERUNGEN

Um x64-Build-Einstellungen verwenden zu können, benötigen Sie das 2016 x64-Datenbankmodul UND den ACE.OLEDB.16.0- Verbindungszeichenfolgenanbieter sowie explizite x64-Build-Einstellungen, um mit Office 365 im Januar 2020 arbeiten zu können. Die Verwendung der Option / passive erleichtert die Installation. Gutschrift an jeden, der diesen Tipp gepostet hat!

Um AnyCPU verwenden zu können, musste sowohl die ACE.OLEDB.12.0 2010 x32-Engine als auch die ACE.OLEDB.16.0 x64-Engine installiert sein. Auf diese Weise konnte Vstudio sowohl x32- als auch x64-Engines zur Kompilierungszeit von "AnyCPU" sehen. Ich könnte die Provider-Verbindungszeichenfolge für den x32-Betrieb in ACE.OLEDB.12.0 oder für den x64-Betrieb in ACE.OLEDB.16.0 ändern. Beide haben gut funktioniert.

Um die x86-Build-Einstellungen verwenden zu können, benötigen Sie das 2010 x32-Datenbankmodul UND den ACE.OLEDB.12.0- Verbindungszeichenfolgenanbieter sowie explizite x86-Build-Einstellungen, um im Januar 2020 mit Office 365 x32 arbeiten zu können.

Ich habe ein ähnliches Problem, wenn wir eine Excel-Datei lesen.

Geschichte des Problems:

Wir haben unsere Anwendung kürzlich aufgrund des Speicherbedarfs von 32-Bit auf 64-Bit migriert. Dafür haben wir unser Windows 7 von 32-Bit auf 64-Bit migriert. Trotzdem haben wir 32-Bit-Office auf unseren Computern installiert.

Aus diesem Grund hatten wir dieses Problem beim Importieren von Excel-Daten in die Anwendung.

Lösung,

Ich habe die 64-Bit-Version von http://www.microsoft.com/en-us/download/details.aspx?id=13255 heruntergeladen und mit dem Argument as installiert:

AccessDatabaseEngine_x64.exe / passive

Ohne Codeänderung wird mein Problem behoben.

Hinweis:

Unter 64-Bit-Betriebssystemen und 64-Bit-Office funktionierte meine Funktionalität ohne dieses Update einwandfrei. Dieser Fix ist nur erforderlich, wenn unsere Anwendung 64-Bit auf einem 64-Bit-Betriebssystem ausgeführt wird, auf dem 32-Bit-Office installiert ist.

Laden Sie einfach die folgende Access DB-Engine herunter und installieren Sie sie (X86 oder X64: gemäß Ihrer Computerkonfiguration) und sehen Sie die Magie :)

https://www.microsoft.com/en-us/download/confirmation.aspx?id=13255

Ich folgte den Anweisungen anderer; Installieren dieses Patches, Installieren dieses Patches sowie des Microsoft Access Database Engine 2010.

Mein Problem war, dass ich dieselbe Bibliothek (linq2sql) an zwei Standorten auf meinem Computer verwende. 1 funktioniert und 1 nicht.

Schließlich stellte ich fest, dass ich in den erweiterten Einstellungen des Apppools für meine nicht funktionierende Site "32-Bit-Anwendungen aktivieren" musste.

Jetzt funktioniert alles gut.

kann auch diese Schritte versuchen

In SQL Server 1.Öffnen Sie eine Datenbank 2.Clic in der Option 'Server Obtect' 3.Clic in 'Linked Servers' 4.Clic in 'Providers' 5.Clic Rigth in 'Microsoft.ACE.OLEDB.12.0' 6. Deaktivieren Sie alle Optionen und schließen Sie sie

Denken Sie daran, AccessDatabaseEngine auf dem Server für Webanwendungen zu installieren .

Ich hatte das gleiche Problem, aber in diesem Fall Microsoft-Ace-Oledb-12-0-Anbieter bereits auf meinem Computer installiert und funktionierte für andere entwickelte Anwendungen.

Der Unterschied zwischen dieser Anwendung und der Anwendung, bei der ich das Problem hatte, bestand darin, dass die alten Anwendungen auf " Local IIS " ausgeführt wurden, während die fehlerhafte Anwendung auf " IIS Express (unter Visual Studio") ausgeführt wurde. Also was ich tat war-

1. Klicken Sie mit der rechten Maustaste auf Projektname.
2. Gehen Sie zu Eigenschaften
3. Gehen Sie zur Registerkarte Web auf der rechten Seite.
4. Wählen Sie unter Server die Option Lokales IIS aus und klicken Sie auf die Schaltfläche Virtuelles Verzeichnis erstellen.
5. Führen Sie die Anwendung erneut aus und es hat funktioniert.

Ich hatte Microsoft Access Database Engine 2010 Redistributable bereits auf meinem Computer installiert, erhielt aber weiterhin den Microsoft ACE OLEDB-Anbieter Fehler.

Dann erinnerte ich mich, dass ich kürzlich ein Upgrade auf Office 2016 durchgeführt hatte. Vielleicht sollte ich versuchen, Microsoft Access Database Engine 2010 Redistributable neu zu installieren . Und das hat das Problem auf meinem Computer behoben.

Wenn Sie also ein Upgrade auf eine andere Version von MS Office durchgeführt oder Ihr MS Office sogar repariert / neu installiert haben, versuchen Sie, Microsoft Access Database Engine 2010 Redistributable erneut zu installieren, bevor Sie Zeit mit der Suche nach anderen Fixes verschwenden. Viel Glück!

1.) Überprüfen Sie Ihre Verbindungszeichenfolge mit ConnectionStrings.com .

2.) Stellen Sie sicher, dass Sie das richtige Datenbankmodul installiert haben. Dies waren die beiden Datenbank-Engines, die mir geholfen haben.

Microsoft Access Database Engine 2010 Weiterverteilbar

2007 Office-Systemtreiber: Datenkonnektivitätskomponenten

3.) Möglicherweise liegt ein Problem damit vor, dass Ihre Build-Zielplattform "Beliebige CPU" ist. Möglicherweise muss sie "X86" sein (Eigenschaften, Build, Plattformziel).

Wenn Sie diesen Fehler erhalten, wenn Sie versuchen, ACE aus einer ASP.NET-Anwendung heraus zu verwenden, ist die wahrscheinlichste Ursache, dass Sie eine der 32-Bit-Versionen installiert haben. Standardmäßig führt IIS unter einem 64-Bit-Betriebssystem Anwendungen in einem 64-Bit-Arbeitsprozess aus. 64-Bit-Prozesse können keine 32-Bit-DLLs laden. Wenn ein Anruf beim ACE-Anbieter getätigt wird, versucht der 64-Bit-Prozess, eine 64-Bit-DLL zu finden. Wenn es nicht existiert, erhalten Sie die Fehlermeldung, die Sie hierher gebracht hat.

In diesem Fall haben Sie zwei Möglichkeiten. Zunächst können Sie die 64-Bit-Version 2010 installieren. Wenn Sie die 2007 32-Bit-Version installiert haben, können Sie einfach die 2010 64-Bit-Version daneben installieren. Wenn Sie die 32-Bit-Version von 2010 installiert haben, müssen Sie sie deinstallieren und stattdessen die 64-Bit-Version 2010 herunterladen und installieren. Sie können nicht gleichzeitig die 32- und die 64-Bit-Version des 2010-Anbieters installieren. Wenn Sie die Installation auf Ihrem Entwicklungscomputer durchführen, können Sie auch durch die Bitterkeit vorhandener Office-Installationen eingeschränkt sein.

Die zweite Option besteht darin, den Anwendungspool in IIS zu ändern, um 32-Bit-Anwendungen zu aktivieren. Wenn Sie die Vollversion von IIS verwenden, können Sie dazu das Verwaltungstool verwenden (Systemsteuerung »Verwaltung» IIS-Manager (Internet Information Services)).

Weitere Informationen finden Sie unter dem folgenden Link

Ich habe diesen Fehler beim Importieren von Daten aus einer Excel-Datei in MS-SQL erhalten. Der Provider war bereits installiert (64-Bit) und das überraschte mich, warum es nicht funktionierte. Also habe ich nur die hier verwendete Import / Export-Anwendung gefunden, dh die .EXE. Und ich fand es bei

C: \ Programme \ Microsoft SQL Server \ 130 \ DTS \ Binn \ DTSWizard.exe

Ich habe dann die EXE-Datei direkt ausgeführt, um den Datenimport durchzuführen. Und es hat funktioniert!

Das hat jetzt bei mir funktioniert.

1. Besuchen Sie diese Seite und laden Sie das entsprechende Paket für Ihren Computer herunter (AccessDatabaseEngine.exe oder AccessDatabaseEngine_X64.exe).
2. Installieren Sie das.
3. Viel Spaß ... Ihre Codes funktionieren jetzt ...

Für Ihr Anwendungspaket können Sie jedoch eine der folgenden Lösungen verwenden:

4. Gehen Sie zu "C: \ Programme (x86) \ Gemeinsame Dateien \ Microsoft Shared" oder "C: \ Programme \ Gemeinsame Dateien \ Microsoft Shared" und legen Sie das Verzeichnis "OFFICE14" am selben Speicherort Ihrer Paketdatei ab.

Oder

4. Fügen Sie Ihrem Installationspaket zwei Projekte (in Punkt 1) hinzu.