Nächtliche Ausführung eines DTSX-Pakets schlägt fehl

Question

Hallo zusammen,
wir laden Nachts Daten per DTSX-Paket in unser Data Warehouse. Seit einiger Zeit haben wir das Problem, dass sich ein Datenfile (FlatFile --> CSV) sich nicht öffenen lässt.

Die Fehlermeldung lautet:

   Errormessage from DataFlow: 'Cannot open the datafile "\\ServerName\Share\FlatFile.csv".
   Flat File Source failed the pre-execute phase and returned error code 0xC020200E.

Ich bin beim Googeln mehrfach auf die Aussage gestoßen, dass hier wohl ein Rechteproblem vorliegt. Da aber weitere DTSX-Pakete aufgerufen werden die die FlatFiles aus dem immer gleichen Verzeichnis erfolgreich laden, kann ich mir das nicht vorstellen. Es ist immer der gleiche Benutzer der die Pakete aufruft...der zudem im DWH-Bereich überall Adminberechtigung hat.

Vielen Dank für Eure Tipps, Tricks und Hilfestellungen :)

@Edit: Wir verwenden SQL Server 2014 mit entsprechenden SSIS auf einem Windows Server 2012 R2...

---

Viele Grüße Holger M. Rößler

Answer 1

Hallo Holger,

kopier die Datei mal und teste es mit der Kopie. Neben Berechtigungsproblemen kommt der Fehler anscheinend auch, wenn die Datei durch eine andere Anwendung noch im Zugriff ist. Evtl. liegt es daran. (Ggfs. auch ein Virenscanner oder ähnliches)

Mittels SysInternals Process Monitor solltest Du genauer sehen können, was eigentlich schief geht.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

Answer 2

Sowas kenne ich auch aus anderen Situationen (BI-Importe). Hier ist ggf. eine mangelhafte Synchronisation zwischen Import und Erstellung der Datei die Ursache. Da ist es schon besser, die Daten nicht zu importieren da sie ja unvollständig sein können.

Vielleicht kannst du ja mal die Eigenschaften bzgl. Erstellungsdatum/-zeit und Importzeitpunkt prüfen.

Answer 3

Hallo bfuerchau,
vielen Dank für deine Anregung. Der Erstellungszeitpunkt liegt aber definitiv vor Importzeitpunkt.

Die Software die die DTSX-Pakete startet wartet nicht auf das Datenfile selbst, sondern auf eine Datei die sequentiell nach dem Datenfile geschrieben wird, das von uns genannte Triggerfile. Erst wenn dieses Triggerfile vorhanden ist (das ja sequentiell nach dem Datenfile geschrieben wird), wird das DTSX-Paket gestartet. Sprich das Datenfile sollte in der Zwischenzeit fertig geschrieben sein.

Das sollte nicht das Problem sein, sonst hätten wir bei anderen Paketen sehr wahrscheinlich das gleich Problem.

---

Viele Grüße Holger M. Rößler

Answer 4

Hallo Stefan,
auch dir vielen Dank für dein Idee.

Das "Problem" dabei ist, wenn das Paket morgens oder über den Tag manuell angestoßen wird, läuft es sauber durch. Wir haben dieses Problem also nur während der Nachtverarbeitung, aber nur bei diesem einen DTSX-Paket...

---

Viele Grüße Holger M. Rößler

Answer 5

Hallo Holger,

das spricht aber für meine Theorie, dass die Datei noch im Zugriff ist.

---

Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

Answer 6

Hallo Stefan,
das könnte durchaus sein.

Ich werde das Mal im Auge behalten. Auf das Gleiche wollte bfuerchau ja auch hinaus. Ich werde daher in der Ladesoftware für dieses Paket mal eine Ladeverzögerung von 10 Sekunden einbauen.

Sollte dies aber wirklich der Fall sein, dann werden die Triggerfiles aber doch nicht sequentiell geschrieben und der Kollege kriegt dann mal sanfte haue. :D

Danke vorerst mal...ich melde mich wieder sowie ich das getestet habe (am Freitag kommt die neue Softwareversion auf die Server).

---

Viele Grüße Holger M. Rößler

Answer 7

Prüfe mal, ob diese "Triggerdatei" auch vor dem Erstellen entfernt wird.

Per Eigenschaften der Dateien (oder Spalteneinblendung in Detailsicht-Explorer des CreationDate), wann die jeweiligen Dateien erstellt werden.

Bei Windows (habe ich jedefalls festgestellt), wird beim Erstellen bzw. Überschreiben einer Datei das CreationDate des Vorgängers übernommen. Man muss die Datei vorher tatsächlich löschen und nicht in den Papierkorb verschieben.

Answer 8

Hallo bfuerchau,
guter Einfall!

Ich habe gerade nachgesehen. Es befinden sich keine Triggerfiles mehr in dem Verzeichnis.

---

Viele Grüße Holger M. Rößler

Answer 9

Dann warten wir mal auf Freitag;-).

Dabei fällt mir allerdings noch ein:
Wie werden die Dateien denn in das Verzeichnis übertragen?
Ist dabei dann sichergestellt, dass die Triggerdatei auch tatsächlich die Letzte ist?

Answer 10

Da läuft ein Skript von unserem Admin-Team, dass die Tabellen aus einer Progress Datenbank unseres ERPs in jeweils ein CSV-File schreibt, und die Files anschliessend auf eine SAN überträgt, auf die die Ladesoftware pollt.

Im Exportskript ist definiert, dass das Triggerfile erst generiert wird, wenn das Datenfile übertragen wurde...

---

Viele Grüße Holger M. Rößler

Answer 11

Hallo zusammen,
ihr hatte recht! Das File wird tatsächlich versucht zu früh zu öffnen. Ich habe unsere Ladesoftware so umgebaut, dass jetzt für jede Datei ein delay hinterlegt werden kann. Ein delay von 10 Sekunden hat Wunderbewirkt.

Ich habe daraufhin am Montag den verantwortlichen Kollegen mit meinem Faschings Lichtschwert "gekizelt", als drakonische Bestrafung! :D

Vielen Dank für eure Hilfe :)

---

Viele Grüße Holger M. Rößler