Fragensteller
SSIS Excel auslesen Access Runtime 2013

Frage
-
Hallo an alle,
ich habe eine XLSX-Datei vorliegen die mit Excel 2010 (32 Bit) erstellt wurde. Diese möchte ich mit SSDT also SSIS auslesen.
Hierzu habe ich die Access Runtime 2013 x86 installiert.
Nach der erfolgreichen Installation wird leider der Treiber noch immer nicht im SQL Server angezeigt.
Was mache ich falsch? Unter ODBC Quellen auf dem Server sehe ich meine Treiber.
Muss ich eigentlich eine Access Runtime x86 oder x64 instalieren. Der Server ist ein x64 aber die Excel-Datei stammt von einem x86 Excel.
Danke schon mal vorab.
Alle Antworten
-
Hallo Toot!
Schau doch mal hier rein: Laden von Daten aus oder in Excel mit SQL Server Integration Services (SSIS)
Du brauchst keine Runtime, sondern dieses hier: Microsoft Access Database Engine 2016 Redistributable
Das natürlich in der Version, die zum SQL Server passt, also hier 64-Bit.
Falls dann bei der Installation Meldungen kommen, es gibt bereits 32 Bit Komponenten, dann diese erst entfernen. Alternativ kann man auch 32-Bit und 64-Bit parallel installieren mit der Quiet-Installationsmethode.
C:\temp\AccessDatabaseEngine.exe /quiet
HTH!
Einen schönen Tag noch, Christoph - http://www.insidesql.org/blogs/cmu
-
Hallo Christoph,
leider kam ich noch nicht zum testen.
Ist es egal welche Version ich installiere? Sprich kann ich die 2016er installieren und es können auch ältere Excel-Versionen ausgelesen?
Also Abwärtskompatibel? Vielleicht kannst du ja hier noch einen Erfahrungsbericht geben.
Vielen Dank.
-
Ja das ist korrekt, die aktuelle Runtime liest auch ältere Excels, so wie Excel ja auch alte Dokumente (XLS) lesen kann.
Bei der Installation von 64-Bit wirst du gewarnt, dass eine andere Version, nämlich 32 Bit installiert ist. Du musst diese also vorher deinstallieren.
Alternativ klappt auch der /Quiet Parameter, allerdings nur bei "Als Admin ausführen". -
Ja, das ist egal. Lediglich ältere Versionen vom Management Studio konnten nicht mit der 2016er Version umgehen. Aber das dürfte mittlerweile Geschichte sein.
@Der Suchende: Du meintest bestimmt nicht die Runtime, sondern die Database Engine (s.o.)!
Einen schönen Tag noch, Christoph - http://www.insidesql.org/blogs/cmu
-
Nein ich meine die AccessRuntime. Die reduzierte DatabaseEngine kannte ich bisher nicht. Da kann ich mir ja nun ein wenig Platz sparen;-).
Dies reduziert allerdings nicht die allgemeinen Installationsprobleme wenn man Office einer Bitness bereits installiert hat und die andere Bitness zusätzlich benötigt. -
hallo an alle,
der Treiber ist installiert und trotzdem bekomme ich keine Möglichkeit eine Excel 2016 Datei auszulesen.
Fehlermeldung aus Visual Studio für SSIS:
The requested OLE DB provider Microsoft.ACE.OLEDB.16.0 is not registered.
If the 32-bit driver is not installed, run the package in 64 mode.
Der SQL Server ist ein 64 Bit Server nur Excel liegt in 32 Bit vor auf dem Client welches die Excel-Datei erstellt hat.
Somit müsste doch die Thematik mit dem 32 Bit Treiber uninteressant sein. Wie könnte ich trotzdem prüfen ob der 32 Bit Treiber sauber installiert ist?
Der SQL Server sagt mir das er den Treiber nutzen könnte.
Kann noch jemand helfen?
-
Dort wo Visual Studio installiert ist muss der 32-Bit Treiber installiert sein, da VS nur 32 Bit ist.
Visual Studio läuft bei mir normalerweise nicht auf dem Server.
Einen schönen Tag noch, Christoph - http://www.insidesql.org/blogs/cmu
-
The requested OLE DB provider Microsoft.ACE.OLEDB.16.0 is not registered.
Aus mir noch unerfindlichen Gründen muss man bei Verwendung derselben Installationsdatei manchmal 12.0, manchmal 15.0 und ganz selten mal 16.0 angeben. Es mag sein, dass das an irgendwelchen, auf den Zielsystemen ggfs. vorher bereits mal installierten Versionen oder anderen Komponenten liegt. Bislang hatte ich noch nicht die Zeit und die Lust, das zu untersuchen.
Ändere daher mal die Versionsnummer im ConnectionString, also bspw.:
Microsoft.ACE.OLEDB.12.0
oder
Microsoft.ACE.OLEDB.15.0
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport -
Schon oft genug erklärt:
Die Anwendung entscheidet über die Bitness. Da Treiber i.d.R. DLL's sind und DLL's der selben Bitness angehören müssen, müssen halt die Treiber entsprechend verfügbar gemacht werden.
Dies ist bei den Access-Treibern halt mit Schwierigkeiten verbunden, da die gleichzeitige Installation in 32- und 64-Bit nur im /Quiet-Modus als Admin möglich ist.
Die Installation beauptet allerdings, dass alles installiert ist, auch wenn man nicht "als Admin ausführen" gewählt hat.Für mich erklärt sich auch nicht, warum Visual-Studio immer noch eine 32-Bit-Anwendung ist.
Visualstudio auf dem Server zu installieren, auf dem man SSIS programmieren möchte macht halt durchaus Sinn.
Wenn man mit Roaming-Profilen arbeitet benötigt man halt nur 1 Installation.Die Version des Treibers spielt i.Ü. keine Rolle, da die sog. CLSID immer die selbe ist und somit grundsätzloch die letzte Version gewählt wird.
In der Registry findet man die ID's für 64-Bit unterHKCR/Microsoft.ACE.OLEDB.nn.0
HKLM/SOFTWARE\Classes\Microsoft.ACE.OLEDB.nn.0
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes
und unter "..../WOW6432Node/... " findet man die passenden 32-Bit-Verweise.
Hier sucht man allerdings die "Microsoft.ACE..." vergeblich, hier benötigt man für die Suche die CLSID:
{3BE786A0-0366-4F5C-9434-25CF162E475E}
Im Verzeichnis (versionsabhängig, Installationsart)
HKCU\SOFTWARE\Microsoft\SQL Server Management Studio\14.0_Config\DataProviders
findet man die benötigten Treiber-Namen für den Manager.
Ebenso für Visual-Studio (je Version):
HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\10.0_Config\DataProvidersDas schöne bei den identischen CLSID's ist, dass man fehlende Einträge aus dem vorhandenen Eintrag einfach duplizieren kann. Die neueren Treiber installieren die Registrykey für die vorherigen Versionen nicht mit.
Dies ist unter HKCR durchzuführen.Das Component-Object-Model (COM) sucht erst unter HKCR die CLSID zur sog. "ProgramId". Erst mit der CLSID wird dann der Server (Inprocserver bei DLL's) in den Verzeichnissen HKLM bzw. HKCU ermittelt.
- Bearbeitet Der Suchende Donnerstag, 25. März 2021 09:32
-
Hallo an alle,
was ich hinbekommen habe ist das mein Visual Studio Excel-Dateien von Excel 2016 ausführen kann. Nun habe ich das ganze in eine DTSX Paket gepackt. Erst wird die Tabelle geleert und danach das Excel-File ausgelesen und danach in die Tabelle geschrieben.
Auch hier gilt im VS läuft alles super. Nur wenn ich das DTSX Paket in den SQL Server Agent einbinde bekomme ich stets die Fehlermeldung "Der Schritt hat keine Ausgabe generiert. Der Rückgabewert war unbekannt."
Die Regeinträge wie Der Suchende geschrieben hat, sind vorhanden. In meiner Not habe ich schon einen Proxy für den SQL Server Agent aufgesetzt, der das DTSX Paket ausführt. Dieser Proxy ist Domainadmin, somit ist das eventuelle Zugriffsproblem umgangen.
Es sieht aber so aus als ob ich noch immer die Exceldatei nicht öffnen kann. Oder sehe ich das falsch?
Nachtrag: wenn ich das Excel-File öffne, erhalte ich stets noch den Warnhinweis Sicherheitswarnung: Datenverbindungen wurden deaktiviert. Das sollte aber auch nicht das Problem sein.
Ich bin für jeden Tipp dankbar!
- Bearbeitet Toot_Braunstein Mittwoch, 9. Juni 2021 13:39
-
Der Warnhinweis kommt ja sicherlich als Dialog-Meldung, was im Batch nicht möglich ist.
Du kannst also nur Excel-Dateien verwenden, die keine Datenverbindungen enthalten um die Warnung zu unterbinden.
Möglicherweise reicht hier auch, nach dem Erstellen des Excel.Application-Objekts die Einstellung
Application.DisplayAlerts = False
Damit sollten dann Dialogmeldungen unterbleiben.
Für DTSX empfehle ich aber eher, die Excel-Datei als CSV zu exportieren, da man dann den ganzen Overhead und die Installation von Office auf dem Server nicht benötigt. -
So einen kleinen Schritt bin ich weiter.
Ich lasse das Paket über einen Proxy ausführen damit ich ein Thema Netzwerkzugriff ausschließen kann.
Auch lasse ich das Paket in 32-Bit ausführen. Damit komme ich an sich in die Datei und kann Sie im Visual Studio auslesen und auch komplett abarbeiten zb. nächster Schritt die Infos in eine Datenbank packen.
Jedoch klapp das nicht über den SQL Server Agent. Hier erhalte ich nachfolgende Fehlermeldung:
Meldung Ausgeführt als Benutzer: ---------. Microsoft (R) SQL Server-Paketausführungsprogramm Version 14.0.3356.20 für 32 Bit Copyright (C) 2017 Microsoft. Alle Rechte vorbehalten. Gestartet: 16:42:02 Fehler: 2021-06-15 16:42:03.38 Code: 0xC0202009 Quelle: Import Excel-Datei Excel-Quelle [2] Beschreibung: SSIS-Fehlercode "DTS_E_OLEDBERROR". OLE DB-Fehler. Fehlercode: 0x80040E37. Fehlerende Fehler: 2021-06-15 16:42:03.38 Code: 0xC02020E8 Quelle: Import Excel-Datei Excel-Quelle [2] Beschreibung: Fehler beim Öffnen eines Rowsets für "'Alle Zeilen Verkauf ZuAbschläge$'". Überprüfen Sie, ob das Objekt in der Datenbank vorhanden ist. Fehlerende Fehler: 2021-06-15 16:42:03.44 Code: 0xC004706B Quelle: Import Excel-Datei SSIS.Pipeline Beschreibung: Fehler beim Überprüfen von 'Excel-Quelle'. Überprüfungsstatus: 'VS_ISBROKEN'. Fehlerende Fehler: 2021-06-15 16:42:03.44 Code: 0xC004700C Quelle: Import Excel-Datei SSIS.Pipeline Beschreibung: Fehler beim Überprüfen von mindestens einer Komponente. Fehlerende Fehler: 2021-06-15 16:42:03.44 Code: 0xC0024107 Quelle: Import Excel-Datei Beschreibung: Fehler bei der Tasküberprüfung. Fehlerende DTExec: Die Paketausführung wurde beendet. DTSER_FAILURE (1). Gestartet: 16:42:02 Beendet: 16:42:03 Verstrichen: 0.562 Sekunden. Fehler beim Ausführen des Pakets. Fehler bei Schritt.
Es scheint so als ob er nicht auf das Excel-Arbeitsblatt kommt.
Hat hier noch jemand eine Idee? Aber warum funktioniert es im VS und nicht im Agent?
-
Das würde ich gern probieren. Aus VS erhalte ich eine DTSX-Datei die ich SSIS gemäß über einen Agent ausführen lassen. Wie würde dein Vorschlag aussehen?
Ich würde gerne verstehen warum es im SQL Server Agent nicht funktioniert und von daher deinen Weg auch einmal testen.
Es muss doch einen Grund geben warum es aktuell nicht funktioniert.
-
Hier ist ein ähnlicher Fehler mit divesen Ansätzen der Lösung:
https://stackoverflow.com/questions/37923721/ssis-error-code-0x80040e37
https://stackoverflow.com/questions/24541013/ssis-error-on-access-import/33768730Was meine pesönliche Lösung angeht so habe ich einen eigenen ETL-Prozess (ohne SSIS), der zwar nicht so viel kann wie SSIS allerdings für ETL vollkommen ausreicht.
Ich lade via ODBC/OLEDB von beliebigen Datenquellen und per Namesmatching mit der Zieltabelle schreibe ich die Daten in die Datenbank. Im Falle des SQL-Servers nehme ich sogar den SqlBulkCopy (.Net-Klasse).Namesmatching ist deshalb ja möglich, dass man beim Source-SQL die Felder umbenennen kann so dass sie zum Ziel passen. Typanpassungen werden dabei ebenso automatisiert.Und noch besser: Ich habe 2 Start-Exe's, 1x32 und 1x64 Bit, dei dann dieselbe Komponenten-DLL verwendet um dem Problem der unterschiedlichen Treiberversionen aus dem Weg gehen zu können.