12
SSIS-Paket läuft nicht als Job
Hallo,
ich habe ein SSIS-Paket, das in der Entwicklungsumgebung sowie als Stored Package einwandfrei läuft.
Trage ich es aus Job ein, so funktioniert das Paket nicht. Genau genommen hängt es sich auf.
Gruß
cheapy
Das Paket ist folgendermaßen aufgebaut:
Ich habe einen ForLoop Container, in dem sich ein Execute-Container befindet.
Dieser Container enthält drei Schritte:
Schritt1 ist ein VB-Script, dass in einem Verzeichnis auf einem Netzlaufwerk Dateien sucht und jeweils eine noch nicht bearbeitete Datei in eine Datei mit einem festgelegten Namen kopiert. Die Namen der bereits verarbeiteten Dateien werden in einer Tabelle gespeichert.
Nach dem Kopieren der Datei werden die Daten dieser Datei mit einer DataFlow Task in eine Datenbanktabelle kopiert.
Anschließend wird der Name der gelesenen Quelldatei in eine Datenbanktabelle geschrieben.
Danach durchsucht dann wieder das Script das Verzeichnis nach weiteren nicht gelesenen Dateien.
Sind alle Dateien bearbeitet, kommt das Script mit dem Status Complete zurück und der/die Container sind fertig.
Das Problem ist nun wohl, dass das Script ein Problem hat.
Da ich keine bessere Testmöglichkeit kenne, habe ich vor und nach dem Script eine Send Mail Task eingebaut.
Da die Task die nach dem Script eine Mail mit dem Namen der gerade bearbeiteten Datei versenden soll nicht zum Zuge kommt, vermute ich, dass das VB Script ein Problem hat, denn der Auftrag als Job läuft.
Kann mir jemand sagen, wie ich dem Fehler auf die Spur kommen kann?
Um es vorweg zu nehmen:
Versuche den Job über einen Proxy-User laufen zu lassen und die Verwendung einer URL anstatt eines Pfadnamens haben ebenfalls zu keinem Ergebnis geführt.
Kann mir jemand einen Tipp geben, wie ich der Sache auf die Spur kommen kann?
ich habe ein SSIS-Paket, das in der Entwicklungsumgebung sowie als Stored Package einwandfrei läuft.
Trage ich es aus Job ein, so funktioniert das Paket nicht. Genau genommen hängt es sich auf.
Gruß
cheapy
Das Paket ist folgendermaßen aufgebaut:
Ich habe einen ForLoop Container, in dem sich ein Execute-Container befindet.
Dieser Container enthält drei Schritte:
Schritt1 ist ein VB-Script, dass in einem Verzeichnis auf einem Netzlaufwerk Dateien sucht und jeweils eine noch nicht bearbeitete Datei in eine Datei mit einem festgelegten Namen kopiert. Die Namen der bereits verarbeiteten Dateien werden in einer Tabelle gespeichert.
Nach dem Kopieren der Datei werden die Daten dieser Datei mit einer DataFlow Task in eine Datenbanktabelle kopiert.
Anschließend wird der Name der gelesenen Quelldatei in eine Datenbanktabelle geschrieben.
Danach durchsucht dann wieder das Script das Verzeichnis nach weiteren nicht gelesenen Dateien.
Sind alle Dateien bearbeitet, kommt das Script mit dem Status Complete zurück und der/die Container sind fertig.
Das Problem ist nun wohl, dass das Script ein Problem hat.
Da ich keine bessere Testmöglichkeit kenne, habe ich vor und nach dem Script eine Send Mail Task eingebaut.
Da die Task die nach dem Script eine Mail mit dem Namen der gerade bearbeiteten Datei versenden soll nicht zum Zuge kommt, vermute ich, dass das VB Script ein Problem hat, denn der Auftrag als Job läuft.
Kann mir jemand sagen, wie ich dem Fehler auf die Spur kommen kann?
Um es vorweg zu nehmen:
Versuche den Job über einen Proxy-User laufen zu lassen und die Verwendung einer URL anstatt eines Pfadnamens haben ebenfalls zu keinem Ergebnis geführt.
Kann mir jemand einen Tipp geben, wie ich der Sache auf die Spur kommen kann?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 150475
Url: https://administrator.de/forum/ssis-paket-laeuft-nicht-als-job-150475.html
Ausgedruckt am: 11.04.2025 um 18:04 Uhr
12 Kommentare
Neuester Kommentar
Spontan würde ich in dem Fall darauf tippen, dass irgendwas mit den Berechtigungen nicht passt, wenn der Job gestartet wird. Hat der User, unter dem der SQL Server Agent ausgeführt wird ausreichende Rechte auf das Verzeichnis, in dem die Dateien liegen?
Moin,
zuerst siehe Trommelschlumpf ...
Ansonsten kann es alles sein. Wenn Du allerdings das Problem im VB-Script erahnst, läuft es denn wenn Du es per CScript.exe in der CMD abfährst?
Karo
zuerst siehe Trommelschlumpf ...
Ansonsten kann es alles sein. Wenn Du allerdings das Problem im VB-Script erahnst, läuft es denn wenn Du es per CScript.exe in der CMD abfährst?
Karo
Die von Dir genannten Probleme kannte ich schon von anderen Paketen, daher habe ich statt der Kombination Laufwerk\Pfad die URL der Datei angegeben. Weiterhin lasse ich den Job über einen Proxy-User ausführen und das ist der User, mit dem ich mich auf der DB eingeloggt habe und mit dem ich die Pakete zum Testen ablaufen lasse.
Das dürfte es dann wohl nicht sein, da die Rechte dann ja passen müssten, oder habe ich da möglicherweise etwas übersehen?
Das dürfte es dann wohl nicht sein, da die Rechte dann ja passen müssten, oder habe ich da möglicherweise etwas übersehen?
Zitat von @Karo:
Moin,
zuerst siehe Trommelschlumpf ...
Ansonsten kann es alles sein. Wenn Du allerdings das Problem im VB-Script erahnst, läuft es denn wenn Du es per CScript.exe
in der CMD abfährst?
Karo
Moin,
zuerst siehe Trommelschlumpf ...
Ansonsten kann es alles sein. Wenn Du allerdings das Problem im VB-Script erahnst, läuft es denn wenn Du es per CScript.exe
in der CMD abfährst?
Karo
Sorry, das habe ich jetzt nicht verstanden.
Kannst Du mir bitte genauer erklären, wie ich das machen soll?
Da das Script ja in der Entwicklungsumgebung für die Pakete funktioniert - dort kann ich es ja auch debuggen - gehe ich mal davon aus, dass da kein Grundsätzliche Fehler drin ist.
Ich habe leider keine Idee, wie ich bei der Jobausführung möglichen Fehlern auf die Spur kommen kann.
ok, ich verstehe jetzt vielleicht auch was falsch 
Du kannst das Zeug ja durch den Debugger, da läuft es durch und der Fehler kommt nur, wenn Du das SSIS Paket auf dem SQL Server in der Job-Schlange hast?
Wenn Du allerdings annimmst, das VB Script hat ne Macke, dann kannst Du es doch 'trocken' in einer CMD ablaufen lassen nachdem Du die entspreche Umgebung (Pathvariablen, evtl. verbundene Laufwerke etc.) nach gestellt hast, bzw. direkt auf dem ausführendem Server.
Mit der URL meinst Du eher den UNC-Pfad? (\\SERVERNAME\SHARE\Vz\....\DATEINAME)
Karo
Du kannst das Zeug ja durch den Debugger, da läuft es durch und der Fehler kommt nur, wenn Du das SSIS Paket auf dem SQL Server in der Job-Schlange hast?
Wenn Du allerdings annimmst, das VB Script hat ne Macke, dann kannst Du es doch 'trocken' in einer CMD ablaufen lassen nachdem Du die entspreche Umgebung (Pathvariablen, evtl. verbundene Laufwerke etc.) nach gestellt hast, bzw. direkt auf dem ausführendem Server.
Mit der URL meinst Du eher den UNC-Pfad? (\\SERVERNAME\SHARE\Vz\....\DATEINAME)
Karo
Ähäm, ja klar UNC-Pfad.
Ich kann im der VB-Script-Task ja erstmal keinen Fehler feststellen, es muss also doch irgendwas mit den Rechten zu tun haben.
Anscheinend scheint der Proxy die Umgebung doch nicht exakt so einzustellen wie ich sie habe, wenn ich mit der DB arbeite.
Das Problem hatte ich schon bei anderen Jobs, wo die Kombination (Netz)Laufwerk\Pfad nicht funktionierte und ich es erst zum Laufen bekam, nach dem ich auf UNC umgestellt habe.
Aber auch das Script arbeitet schon mit UNC-Pfadangaben.
Kannst Du mir bitte erklären, wie ich das mit CMD anstellen muss?
Ich kann im der VB-Script-Task ja erstmal keinen Fehler feststellen, es muss also doch irgendwas mit den Rechten zu tun haben.
Anscheinend scheint der Proxy die Umgebung doch nicht exakt so einzustellen wie ich sie habe, wenn ich mit der DB arbeite.
Das Problem hatte ich schon bei anderen Jobs, wo die Kombination (Netz)Laufwerk\Pfad nicht funktionierte und ich es erst zum Laufen bekam, nach dem ich auf UNC umgestellt habe.
Aber auch das Script arbeitet schon mit UNC-Pfadangaben.
Kannst Du mir bitte erklären, wie ich das mit CMD anstellen muss?
da es in dem VB-Script um Dateioperationen geht reicht doch ein cscript <VBSCRIPTNAME> in einer CMD aus, um zumindest erst einmal zu erkennen, ob es unter anderen Namen geht. Du kannst natürlich auch %WINDIR%\system32\CMD.exe im Explorer mittels 'ausführen als' mit dem User ausführen unter dem der SQL Job läuft.
Karo
Karo
Es handelt sich um eine Scripttask, die Bestandteil des SSIS-Paketes ist, wie soll ich die denn einzeln ausführen.
Auf der Kommando-Ebene war cscript übrigens nicht bekannt. Gibt es das eventuell unter Windows 2003 Server nicht?
Auf der Kommando-Ebene war cscript übrigens nicht bekannt. Gibt es das eventuell unter Windows 2003 Server nicht?
hm, habe vielleicht ne kleine Fehlinterpretation...
Nochmal für mich: Du hast ein SSIS Paket (achso, von welcher SQL Serverversion sprechen wir hier eigentlich?) in dem Du ein Script Task hast (VB.Net oder VB 2008, siehe auch Frage SQL Version). Dieser Task macht die Dateioperationen. Der wiederum läuft wenn Du es im Debugger laufen läßt aber nicht per Job Schedule?
Wäre es jetzt ein Job Task, das war meine erste Interpretation, so hättest Du per VBS einen CMD Step im Job machen können.
Womit wir beim Thema sind. Denn im SQL Server Job kannst Du das Logging bzw. Ausgabedes Logs anpassen. Das hilft vielleicht.
Karo
Nochmal für mich: Du hast ein SSIS Paket (achso, von welcher SQL Serverversion sprechen wir hier eigentlich?) in dem Du ein Script Task hast (VB.Net oder VB 2008, siehe auch Frage SQL Version). Dieser Task macht die Dateioperationen. Der wiederum läuft wenn Du es im Debugger laufen läßt aber nicht per Job Schedule?
Wäre es jetzt ein Job Task, das war meine erste Interpretation, so hättest Du per VBS einen CMD Step im Job machen können.
Womit wir beim Thema sind. Denn im SQL Server Job kannst Du das Logging bzw. Ausgabedes Logs anpassen. Das hilft vielleicht.
Karo
Zitat von @Karo:
hm, habe vielleicht ne kleine Fehlinterpretation...
Nochmal für mich: Du hast ein SSIS Paket (achso, von welcher SQL Serverversion sprechen wir hier eigentlich?) in dem Du ein
Script Task hast (VB.Net oder VB 2008, siehe auch Frage SQL Version).
===> SQL-Server 2008 / VB 2008hm, habe vielleicht ne kleine Fehlinterpretation...
Nochmal für mich: Du hast ein SSIS Paket (achso, von welcher SQL Serverversion sprechen wir hier eigentlich?) in dem Du ein
Script Task hast (VB.Net oder VB 2008, siehe auch Frage SQL Version).
Dieser Task macht die Dateioperationen. Der wiederum
läuft wenn Du es im Debugger laufen läßt aber nicht per Job Schedule?
===> So ist es!läuft wenn Du es im Debugger laufen läßt aber nicht per Job Schedule?
Wäre es jetzt ein Job Task, das war meine erste Interpretation, so hättest Du per VBS einen CMD Step im Job machen
können.
Womit wir beim Thema sind. Denn im SQL Server Job kannst Du das Logging bzw. Ausgabe des Logs anpassen. Das hilft vielleicht.
===> Mit dem Logging habe ich ja auch schon ergebnislos rumgespielt, das ist ja das Dilemma, Darum ja auch der Versuch, mehrere Sendmail-Tasks einzubauen, womit ich zumindest feststellen konnte, dass die Script-Task wohl nicht beendet wird und daher wiederum meine Vermutung, dass da irgendwas in der Scripttask nicht funktioniert.können.
Womit wir beim Thema sind. Denn im SQL Server Job kannst Du das Logging bzw. Ausgabe des Logs anpassen. Das hilft vielleicht.
Karo
SQL Server-> Jobs -> MEINJOB Proberties -> Steps -> DERSTEP Edit -> Advanced
Hier das Log konfiguriert?
Was steht denn in der History
SQL Server-> Jobs -> MEINJOB -> View History -> Job History. In der rechten Splate sind ja die einzelnen Steps mit den Log-Ausgaben
Karo
Hier das Log konfiguriert?
Was steht denn in der History
SQL Server-> Jobs -> MEINJOB -> View History -> Job History. In der rechten Splate sind ja die einzelnen Steps mit den Log-Ausgaben
Karo
Da steht nur das der Job gestartet wurde und das der erste Step ausgeführt wird.
Nach der Scripttask müssten Daten aus einem Flatfile in eine Tabelle kopiert werden und in einer anderen Tabelle müsste der Name des Flatfiles gespeichert werden.
Beides passiert nicht...
Nach der Scripttask müssten Daten aus einem Flatfile in eine Tabelle kopiert werden und in einer anderen Tabelle müsste der Name des Flatfiles gespeichert werden.
Beides passiert nicht...
