wir haben aktuell das Problem, dass in Berichten eingebettete PDF-Dateien teilweise oder ganz abgeschnitten werden (nur 3 von 5 Seiten vorhanden) oder nur eine leere Seite in der Druckvorschau erzeugt wird. Dies betrifft zwei unserer Kunden:
Nummer 1) Hat die einzubindende PDF-Datei auf Onedrive liegen. (Macht unterwegs Handyhotspot im Edge-Netz auf und druckt dann mit Dokumenten aus dem Netzwerk)
Nummer 2) Hat die PDF-Datei im Firmennetzwerk mit VPN-Verbindung zum Server liegen. (Hat LTE im Laptop verbaut, aber wahrscheinlich auch nur Edge)
Aktuell prüfen wir im C++ Code nur im, ob eine Datei vorhanden ist und dann soll der Reportgenerator die PDF komplett einbinden. Meine Vermutung ist, dass es zu irgendwelchen Timeouts aufgrund von schlechter Datenübertragung kommt und dann das Einbinden weiterer Seiten aus dem PDF abgebrochen wird. Ich kann das Verhalten in unserem Netzwerk oder mit unserer DSL2000-Leitung nicht nachstellen, da funktioniert es.
Gibt es im Report eine Einstellung oder ein Flag, welches man setzen kann, dass die Datenübertragung aus einem langsamen Netz erfolgt, oder sollten wir in Zukunft zuerst alle Netzinhalte in einen lokalen Temp-Ordner kopieren und von dort in den Report einbinden lassen?
Um das vermutete langsame Netz(werk) auszuschließen würde ich wie von dir selbst vorgeschlagen auch erst einmal einen lokalen Download durchführen und dann erst damit weiterarbeiten.
Eine Option in Bezug auf langsame Quellen - sei es in der Datenversorgung oder externer Inhalte für die Berichte - ist mir da nicht weiter bekannt. Höchstens, dass man bei diversen .NET Datenprovidern noch Timeouts definieren/erhöhen könnte. Aber das hilft hier in diesem Fall nicht.
Wenn die Kunden die Datei lokal speichern und von dort einbinden funktioniert alles ohne Probleme.
Auf explizite Nachfrage kommen beim Onedrive-Kunden sogar Fehlermeldungen, die aber scheinbar intern aus List&Labels heraus erzeugt werden. Die Meldungstexte lauten “Metadatei ist ungültig” und “Canvas erlaubt kein”. Die Seiten einer PDF-Datei werden intern doch als EMF gerendert und dann eingebunden, da würden diese Meldungen genau dafür sprechen, dass dabei der Datenstrom abreißt oder ähnliches.
Wir werden dann wohl eine aktivierbare Option einbauen, Netzwerkinhalte vor dem Drucken lokal kopieren zu lassen. Ich freue mich schon auf die Fragen “Warum dauert mein Druck so lange?”
Eine Möglichkeit wäre, erst zu versuchen die PDF-Datei exclusiv zu öffnen.
Geht das nicht, wird die Datei noch beschrieben.
Dasselbe passiert beim Drucken über “MS Print to PDF”, das PDF (Zieldatei) wird angelegt, dann erst beschrieben. Wenn man nur auf Existenz der Datei abfragt und dann die Datei lädt, bekommt man eine fehlerhafte PDF-Datei geliefert.
Die Meldungen kenne ich nicht - wenn wir eine Chance haben, das nachzustellen sehen wir uns das gerne mal an. Ansonsten scheint ja der lokale Download ein guter Workaround zu sein.
