cheaptrick
Goto Top

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?

Content-Key: 150475

Url: https://administrator.de/contentid/150475

Ausgedruckt am: 28.03.2024 um 17:03 Uhr

Mitglied: trommelschlumpf
trommelschlumpf 07.09.2010 um 10:47:46 Uhr
Goto Top
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?
Mitglied: Karo
Karo 07.09.2010 um 11:00:02 Uhr
Goto Top
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
Mitglied: cheaptrick
cheaptrick 07.09.2010 um 11:05:37 Uhr
Goto Top
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?
Mitglied: cheaptrick
cheaptrick 07.09.2010 um 11:12:04 Uhr
Goto Top
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

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.
Mitglied: Karo
Karo 07.09.2010 um 12:55:12 Uhr
Goto Top
ok, ich verstehe jetzt vielleicht auch was falsch face-wink
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
Mitglied: cheaptrick
cheaptrick 07.09.2010 um 13:16:44 Uhr
Goto Top
Ä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?
Mitglied: Karo
Karo 07.09.2010 um 13:22:55 Uhr
Goto Top
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
Mitglied: cheaptrick
cheaptrick 07.09.2010 um 13:33:02 Uhr
Goto Top
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?
Mitglied: Karo
Karo 07.09.2010 um 15:07:42 Uhr
Goto Top
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
Mitglied: cheaptrick
cheaptrick 07.09.2010 um 15:19:16 Uhr
Goto Top
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 2008
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!
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.

Karo
Mitglied: Karo
Karo 07.09.2010 um 15:42:12 Uhr
Goto Top
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
Mitglied: cheaptrick
cheaptrick 07.09.2010 um 15:51:41 Uhr
Goto Top
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...