Benutzer mit den meisten Antworten
Import einer Excel-Datei über SSIS-Paket per xp_cmdshell

Frage
-
Hallo,
folgende Ausgangssituation:
Server1:
Windows Server 200 R2 64bit
MS SQL Server 2008 R2 64bit
MS Office 2010 32bitServer2:
Fileserver mit Freigabe auf Verzeichnisse davon:
Verzeichnis1 = Speicherort SSIS-Paket („Geburt_2013_Test.dtsx“)
Verzeichnis2 = Speicherort Excel-Datei („Geburt_2013.xlsx“).Paket ist konfiguriert mit:
ProtectionLevel = DontSaveSensitiveIch möchte über eine TSQL-Eingabe im Management-Studio vom Client (Aufruf soll später über externe GUI erfolgen) das Paket starten. Das gelingt mir auch, nur das Öffnen der Excel-Datei schlägt fehl mit folgender Fehlermeldung:
Microsoft (R) SQL Server-Paketausführungsprogramm
Version 10.50.2500.0 für 32-Bit
Copyright (C) Microsoft Corporation 2010. Alle Rechte vorbehalten.
NULL
Gestartet: 15:30:31
Status: 2013-09-20 15:30:32.56
Quelle: Datenflusstask
Überprüfung wird ausgeführt: 0% abgeschlossen.
Statusende
Fehler: 2013-09-20 15:30:32.67
Code: 0xC0202009
Quelle: Geburt_2013_Test Verbindungs-Manager 'rd_Geburten_2013'
Beschreibung: SSIS-Fehlercode 'DTS_E_OLEDBERROR'. OLE DB-Fehler. Fehlercode: 0x80004005.
Ein OLE DB-Datensatz ist verfügbar. Quelle: 'Microsoft Access Database Engine' HRESULT: 0x80004005 Beschreibung: 'Das Microsoft Access-Datenbankmodul kann die Datei '' nicht öffnen und nicht in die Datei schreiben. Sie ist bereits von einem anderen Benutzer exklusiv geöffnet, oder Sie benötigen eine Berechtigung, um die Daten anzeigen und schreiben zu können.'.
Fehlerende
Fehler: 2013-09-20 15:30:32.68
Code: 0xC020801C
Quelle: Datenflusstask Excel-Quelle [1626]
Beschreibung: SSIS-Fehlercode 'DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER'. Fehler beim Aufrufen der AcquireConnection-Methode über den Verbindungs-Manager 'rd_Geburten_2013' (Fehlercode: 0xC0202009). Möglicherweise wurden bereits Fehlermeldungen veröffentlicht, die weitere Informationen zum Fehler beim Aufrufen der AcquireConnection-Methode beinhalten.
Fehlerende
Fehler: 2013-09-20 15:30:32.68
Code: 0xC0047017
Quelle: Datenflusstask SSIS.Pipeline
Beschreibung: Fehler beim Überprüfen von 'Komponente 'Excel-Quelle' (1626)'. Fehlercode: 0xC020801C.
Fehlerende
Status: 2013-09-20 15:30:32.68
Quelle: Datenflusstask
Überprüfung wird ausgeführt: 50% abgeschlossen.
Statusende
Fehler: 2013-09-20 15:30:32.68
Code: 0xC004700C
Quelle: Datenflusstask SSIS.Pipeline
Beschreibung: Fehler beim Überprüfen von mindestens einer Komponente.
Fehlerende
Fehler: 2013-09-20 15:30:32.68
Code: 0xC0024107
Quelle: Datenflusstask
Beschreibung: Fehler bei der Tasküberprüfung.
Fehlerende
DTExec: Die Paketausführung wurde beendet. DTSER_FAILURE (1).
Gestartet: 15:30:31
Beendet: 15:30:32
Verstrichen: 1.141 Sekunden
NULL
Der Aufruf erfolgt über folgenden TSQL- Befehl (Aufruf der DTEXEC.EXE in 32bit Version):
DECLARE @returncode int
EXEC @returncode = xp_cmdshell 'C:\Windows\SYSWOW64\CMD.EXE /C C:\"Program Files (x86)"\"Microsoft SQL Server"\100\DTS\Binn\DTEXEC.EXE /f "\\Server2\Verzeichnis1\Geburt_2013_Test.dtsx"'
Da in etliche Foren als Hauptproblem fehlende Berechtigungen angegeben werden, habe ich ein Löschstatement für Testzwecke geschrieben:
DECLARE @returncode int
EXEC @returncode = xp_cmdshell 'C:\Windows\SYSWOW64\CMD.EXE /C DEL \\Server2\Verzeichnis2\Geburt_2013.xlsx'
Dies funktioniert auf Anhieb, die Datei wird gelöscht. Also gehe ich mal davon aus, dass es an den Berechtigungen nicht liegen sollte. Oder unterliege ich da einem Irrglauben?
Da nur ich mit dem Verzeichnis und der Datei arbeite, ist sie weder von mir noch von wem anders geöffnet.
Führe ich das Paket per Doppelklick oder per Paketdesigner aus, läuft es ohne Probleme durch.
Ich habe auch die Variante mit Proxyaccount probiert, mit demselben Ergebnis.
Was mich halt stört ist zum einen der fehlende Dateiname in „ … kann die Datei '' nicht öffnen ….“ und zum anderen wenn die Datei nicht geöffnet werden kann, wieso steht da „Ein OLE DB-Datensatz ist verfügbar.“?
Ich sicherlich was ganz banales, aber ich komme einfach nicht weiter.
Vielen Dank im Voraus.
Antworten
-
Ich weiß zwar jetzt ad hoc auch nicht, wo das problem liegt
aber xp_cmdshell stehe ich eher kritisch gegenüber. Es gibt gute Gründe das deaktiviert zu lassen. Nicht nur auch Sicherheits- sindern auch aus Stabilitätsgründen.
Ich würde den regulären Ansatz über einen SQL Agent Job mit SSIS Step vorschlagen. Das samt klarem Proxy ist dann "sauber".
Möglicherweise behebt es auch das Problem, oder macht es leichter nachvollziehbar.
Andreas Wolter | Microsoft Certified Master SQL Server
Blog: www.insidesql.org/blogs/andreaswolter
Web: www.andreas-wolter.com- Als Antwort vorgeschlagen M. Heitmann Montag, 23. September 2013 13:21
- Als Antwort markiert Otto.Matthias Mittwoch, 25. September 2013 07:48
Alle Antworten
-
Ich weiß zwar jetzt ad hoc auch nicht, wo das problem liegt
aber xp_cmdshell stehe ich eher kritisch gegenüber. Es gibt gute Gründe das deaktiviert zu lassen. Nicht nur auch Sicherheits- sindern auch aus Stabilitätsgründen.
Ich würde den regulären Ansatz über einen SQL Agent Job mit SSIS Step vorschlagen. Das samt klarem Proxy ist dann "sauber".
Möglicherweise behebt es auch das Problem, oder macht es leichter nachvollziehbar.
Andreas Wolter | Microsoft Certified Master SQL Server
Blog: www.insidesql.org/blogs/andreaswolter
Web: www.andreas-wolter.com- Als Antwort vorgeschlagen M. Heitmann Montag, 23. September 2013 13:21
- Als Antwort markiert Otto.Matthias Mittwoch, 25. September 2013 07:48
-
Vielen Dank für die schnelle Antwort Herr Wolter.
Leider brachte die von Ihnen vorgeschlagene Variante auch keinen Erfolg. Die protokollierte Fehlermeldung ist:
Microsoft (R) SQL Server-Paketausfhrungsprogramm
Version 10.50.2500.0 fr 32-Bit
Copyright (C) Microsoft Corporation 2010. Alle Rechte vorbehalten.Die Option '12.0' ist ungltig.
-
Das ist nun aber eindeutig ein Berechtigungsproblem mehr, sondern, wie ich diesem Bruchstück entnehme, eher ein Problem im Aufruf – und die „12“ steht sicher nicht für SQL Server 2014, bleibt der Excel Provider :-)
Haben sie „Verwendung von 32“ (oder so ähnlich) angehakt?
Falls das nicht hilft, wäre ein Screenshot der Einstellungen sicher hilfreich - oder der Code, insbesondere falls manuell editiert
Andreas Wolter | Microsoft Certified Master SQL Server
Blog: www.insidesql.org/blogs/andreaswolter
Web: www.andreas-wolter.com
- Bearbeitet Andreas.WolterMicrosoft employee Montag, 23. September 2013 15:09 ergänzung
-
Eigentlich sollte das funktionieren, Ich kann die Fehlerquelle jetzt nicht identifizieren. Office2010 Treiber sind auf dem Server ja sicherlich installiet.
Man könnte es mal mit den 64 bit Treibern versuchen: http://www.microsoft.com/en-us/download/details.aspx?id=13255
Vielleicht ist auch in diesem Thread noch ein Hinweis, der hilft: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/8a40d329-0611-44e2-ae51-3bd9b0901754/ssis-the-requested-ole-db-provider-microsoftaceoledb120-is-not-registered
Andreas Wolter | Microsoft Certified Master SQL Server
Blog: www.insidesql.org/blogs/andreaswolter
Web: www.andreas-wolter.com -
Guten Morgen,
ich glaub es ist ein grundsätzliches Problem, wenn selbst JET fehlschlägt. Ich habe probehalber den Excelverbindungsmanager auf Office 97-2003 umgestellt (xls-Datei und Jet 4.0). Als Fehler bringt er mir jetzt:
Microsoft (R) SQL Server-Paketausfhrungsprogramm
Version 10.50.2500.0 fr 32-Bit
Copyright (C) Microsoft Corporation 2010. Alle Rechte vorbehalten.Die Option '8.0;HDR=YES;' ist ungltig.
Aber dann verstehe ich nicht wieso, es mit Paketstart per Doppelklick oder im Paketdesigner oder per Importassistent funktioniert, egal ob per JET oder ACE.
-
Da bin ich im Moment überfragt, und habe leider auch keine Zeit das nachzustellen.
Vielleicht weiß noch ein Kollege hier Rat oder hat mehr Zeit.
Ich würde ansonsten gern mal den kompletten Aufruf sehen wollen. Man kann den Job auch scripten, dann sollte alles dabei sein. Irgendwie hängt es ja offenbar am Connection Manager/String
Andreas Wolter | Microsoft Certified Master SQL Server
Blog: www.insidesql.org/blogs/andreaswolter
Web: www.andreas-wolter.com -
Guten Morgen,
wie so oft spielt der Zufall einem in die Hände. Ich habe die Ursache für die Fehlermeldung "Die Option '12.0' ist ungltig." gefunden.
Ich darf bei Verbindungsmanager nichts anhaken.
Fehler tritt auf bei:
Fehler tritt nicht auf bei:
Ich kann es mir nur so erklären: Das Paket ist mit Paketkonfigurationsdatei. Darin sind die Informationen der Verbindungsmanager bereits gespeichert. Bei gesetztem Haken kommt es zu einem Doppelaufruf und dadurch zu dem Fehler "Option 12.0 ist ungültig" (sehr vielsagend).
Ist aber auch nur eine Vermutung. Zumindest funktioniert es jetzt.
Vielen Dank Herr Wolter für die erbrachten Lösungsvorschläge und geopferte Zeit.
- Als Antwort markiert Otto.Matthias Mittwoch, 25. September 2013 07:49
- Tag als Antwort aufgehoben Otto.Matthias Mittwoch, 25. September 2013 07:49
-
Alles klar.
Mit dem Haken würde man normalerweise ja das original "überschreiben" wollen. Das es beim versehentlichen Setzen zu soetwas kommen kann, ist mir noch nicht untergekommen, aber wenn das hier so ist, haben wir was dazugelernt.
Wunderbar das es nun doch klappt wie es sollte.
Andreas Wolter | Microsoft Certified Master SQL Server
Blog: www.insidesql.org/blogs/andreaswolter
Web: www.andreas-wolter.com