none
Import einer Excel-Datei über SSIS-Paket per xp_cmdshell RRS feed

  • Frage

  • Hallo,

    folgende Ausgangssituation:

    Server1:
    Windows Server 200 R2 64bit
    MS SQL Server 2008 R2 64bit
    MS Office 2010 32bit

    Server2:
    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 = DontSaveSensitive

    Ich 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.

    Montag, 23. September 2013 11:40

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
    Montag, 23. September 2013 12:46

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
    Montag, 23. September 2013 12:46
  • 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-Paketausfhrungsprogramm
    Version 10.50.2500.0 fr 32-Bit
    Copyright (C) Microsoft Corporation 2010. Alle Rechte vorbehalten.

    Die Option '12.0' ist ungltig.

    Montag, 23. September 2013 14:33
  • 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

    Montag, 23. September 2013 15:07
  • Also die 0 habe ich auch auf 1 geändert mit dem selben Effekt.

    Möglichen Lösungsvorschlägen würde ich mich dann morgen zuwenden.

    Montag, 23. September 2013 15:46
  • 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

    Montag, 23. September 2013 20:54
  • 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-Paketausfhrungsprogramm
    Version 10.50.2500.0 fr 32-Bit
    Copyright (C) Microsoft Corporation 2010. Alle Rechte vorbehalten.

    Die Option '8.0;HDR=YES;' ist ungltig.

    Aber dann verstehe ich nicht wieso, es mit Paketstart per Doppelklick oder im Paketdesigner oder per Importassistent funktioniert, egal ob per JET oder ACE.

    Dienstag, 24. September 2013 06:59
  • 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

    Dienstag, 24. September 2013 12:37
  • 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 ungltig." 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
    Mittwoch, 25. September 2013 07:48
  • 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

    Mittwoch, 25. September 2013 10:34