Für alle, die immer noch davon betroffen sind.
Ich habe den Fehler bekommen...
OLEDB Fehler "Der 'Microsoft.ACE.OLEDB.12.0'-Anbieter ist auf dem lokalen Computer nicht registriert."
...wie vom OP, Shailesh Sahu, beschrieben.
Ich habe 64-Bit-Windows 7.
Mein Problem liegt in PowerShell-Skripten, die jedoch eine Verbindungszeichenfolge verwenden, ähnlich wie im Post des OPs, also hoffentlich können meine Erkenntnisse auf C#, PowerShell und jede andere Sprache angewendet werden, die auf dem Treiber "Microsoft.ACE.OLEDB" basiert.
Ich habe den Anweisungen in diesem MS-Forumsthread gefolgt: http://goo.gl/h73RmI
Ich habe zuerst versucht, die 64-Bit-Version zu installieren, dann die 32-Bit-Version von AccessDatabaseEngine.exe von dieser Seite installiert http://www.microsoft.com/en-us/download/details.aspx?id=13255
Aber immer noch kein Glück.
Dann habe ich den folgenden Code in PowerShell ausgeführt (von SQL Panda's Website http://goo.gl/A3Hu96)
(New-Object system.data.oledb.oledbenumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION
...das gab mir dieses Ergebnis (ich habe andere Datenquellen der Kürze halber 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.
Also, hier ein schnelles PowerShell-Snippet, um zu demonstrieren, wie man die Version flexibel codiert...
$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`";"
angepasst, um die neueste ACE-Version auszuwählen, wenn mehr als eine vorhanden ist
Hoffentlich können Personen, die dies finden, jetzt überprüfen, welche OLEDB-Version installiert ist und die entsprechende Versionsnummer verwenden.
13 Stimmen
Nur ein kommentar: Die Verwendung von OLEDB zum Lesen einer Excel-Datei ist veraltete Technologie, sehr langsam und wie Sie festgestellt haben, erfordert die manuelle Installation zusätzlicher Pakete auf Ihrem Zielsystem. (Zugegeben, die Frage wurde 2011 gestellt.) Es ist besser, ClosedXml (verfügbar auf NuGet) zu verwenden, das sofort einsatzbereit ist.
7 Stimmen
@ShaulBehr Es wäre schön gewesen, aber ClosedXml funktioniert nur für .xlsx-Dateien, nicht für .xls.
7 Stimmen
Wenn Sie in Sql Server importieren, können Sie diese Abfrage von Ssms ausführen: execute master.dbo.xp_enum_oledb_providers Es wird Ihnen sagen, welche Anbieter es denkt, dass Sie haben. Es hat mir gesagt, dass ich sowohl Microsoft.ACE.OLEDB.16.0 als auch Microsoft.ACE.OLEDB.12.0 hatte, aber als ich versuchte, Daten zu importieren, bekam ich dasselbe 'nicht auf Ihrem lokalen Rechner registriert' wie der OP, sowohl für Excel 16 als auch für Excel 2007 Dateiformate (oledb.16.0 und oledb.12.0 jeweils). Es macht Sinn, an diesem Punkt den Verlust abzuschneiden und sich von der Microsoft-Software zu verabschieden.
1 Stimmen
Auch siehe diese Antwort stackoverflow.com/a/14401857/21579 für den Unterschied zwischen Microsoft.Jet.OleDb und Microsoft.Ace.OleDb.
4 Stimmen
@user1040323,
execute master.dbo.xp_enum_oledb_providers
zeigt dir, was auf dem Server ist, nicht auf deiner lokalen Maschine.6 Stimmen
Hier das, was funktionieren sollte; - Es ist: Nicht wirklich dokumentiert, aber ich habe einen Weg gefunden, beide 32-Bit- und 64-Bit-Versionen zu installieren. Fügen Sie einfach das Kommandozeilenargument "/passive" zum Befehl hinzu: "C:\Verzeichnispfad\AccessDatabaseEngine_x64.exe" /passive