Office: (Office 2007) Drucken von Datensätzen per Bericht als PDF-Datei

Hallo & guten Abend,

Dank der tollen Unterstützung im Thread Drucken von Datensätzen über Bericht mit Vergabe des Dateinamens aus Tabellenfeldern kann ich die selektierten Datensätze über einen Bericht drucken und als PDF-Datei speichern.

Vielleicht passt es ja nicht ganz hierher, aber gibt es eine Möglichkeit in die zu erstellende PDF-Datei ein Feld "einzubauen", in das man wenn man das PDF-Dokument später öffnet in eine Art "TEXTFELD" einen kurzen Text eingeben kann der beim Drucken mit ausgegeben wird ?

Danke für Deine Antwort im Voraus.
Jens

:)

 

Ich merke gerade das ich noch ein ganz anderes Problem habe.

Und zwar wird mir der Dateiname des zu speichernden PDF-Dokumentes über bestimmte Textfelder generiert.

NUN kann es aber passieren das sich wegen einer inhaltlichen Änderung im Datensatz eines oder mehrere dieser Textfelder ändert.

Aus "222499 - 600x800 - Bodo.pdf" würde dann z.B. "222499 - 600x800 - Bodo-KaFo.pdf" werden.
Problem dabei ist nur, dass ich dann 2 verschiedene Dateien habe, von denen die zuerst erstelle überflüssig wäre bzw. hinfällig ist.

Gibt es da ggf. die Möglichkeit vor dem Speichern der Änderungen des aktuellen Datensatzes zu prüfen, ob es eventuell schon eine Datei gibt, die bereits mit den Angaben von vor dem kommenden Update erstellt wurde ?
Und wenn ja, kann man die Datei ggf. auch direkt löschen, sofern sie vorhanden ist?

 

Hallo!

Du kannst den Dateinamen der ursprünglich erstellten PDF-Datei ja in derselben Tabelle oder auch einer weiteren Tabelle speichern.
Ist wegen einer Änderung der Daten der Dateiname auch zu ändern, kannst Du das anhand der Ausgangsdaten feststellen.
Zutreffendenfalls löscht Du die PDF-Datei.
Du kannst Dir aber auch vor Änderung (zB. beim ersten Anzeigen) des Datensatzes immer die zugehörige PDF-Datei ermitteln und irgendwo vormerken.
Wenn eine Änderung auch den Dateinamen beeinflußt kannst Du die vorgemerkte Ausgangsdatei löschen.

Wolfgang

 

Hallo,

mit Dir() prüfen und mit Kill löschen.
Ganz allgemein so:

Code:

Vorsicht, Kill löscht gnadenlos ohne Rückfrage. Daher mit unwichtigen Dateien probieren.

 

Guten Abend (ihr 2),

danke für Eure Tipps. So in dieser Art hatte ich mir es vorgestellt.
Ich denke es macht Sinn generell die "alte" Datei zu löschen, wobei ja bei jetzigen Stand eine ggf. bestehende Datei einfach von der neuen überschrieben wird.

Mir dem folgenden Code speichere ich die Daten über den Bericht als PDF-Datei ab.
Was muss ich denn jetzt noch wie einfügen, dass zuerst geprüft wird ob der Name der zu speichernden Datei bereits vorhanden ist und wenn ja diese gelöscht wird und zur selben Zeit der Dateiname in einer Tabelle namens "Pfade" gespeichert wird, um wiederrum vor dem nächsten Speichern der Datei die Grundlage für die Suche zum Löschen zu bilden ?

Code:

 

Hallo Jens!

Provokant gefragt:

Wo liegt der Unterschied zwischen dem Überschreiben bereits erstellter
PDF-Dateien und dem Erzeugen neuer Dateien bei gleichzeitigem Löschen bereits vorhandener Dateien?
Es wäre bei jeder der beiden Lösungen immer nur die zuletzt erzeugte Datei vorhanden.

Du verwendest für den Bericht den Filter
Filter = "[ID] = " & .Fields("ID")
Diese ID dürfte doch jeden Bericht eindeutig identifizieren?
Was auch immer für Daten im Bericht selbst enthalten sind?

Wenn das stimmt, so wäre diese ID im Dateinamen anstelle Deiner Klimmzüge zu verwenden.
Damit überschreibts Du bereits erzeugte Dateien mit derselben ID.
Und wann die Datei erzeugt wurde ist sowieso immer gespeichert.
Damit entfiele auch eine historische Speicherung der PDF-Dateinamen.

Wenn Du ein schlüssiger Argument dagegen hast, dann bitte hier posten.

Wolfgang

 

Guten Abend (Wolfgang),

Du sprichst von 2 Lösungen und ich dachte eben, es wäre rein von der Prozedur her gesehen "einfacher" diese vom Code her zu gestalten. Andererseits MUSS die "alte" Datei immer gelöscht werden, gerade wenn sich eines der Kriterien für den Dateinamen ändert.
Wenn sich natürlich nur bei anderen Daten etwas ändert, wäre es natürlich ausreichend wenn die Datei einfach überschrieben wird.

Der Unterschied ist folgender, man bedenke, ändern sich die Kriterien innerhalb des Datensatzes für den Dateinamen, ändert sich auch der Dateiname. In diesem Fall, gibt es ja keine Datei die bei gleichlautendem Dateinamen überschrieben werden kann und es muss die "alte Version" vor dem Speichern der neuen gelöscht werden.
Ändern sich hingegen nur andere Daten im Datensatz würde natürlich ein Überschreiben reichen.

Ja, die ID ist natürlich immer eindeutig, unabhängig davon was für Daten im Bericht stehen.
ABER die ID als Dateinamen zu verwenden muss ich leider verneinen, WEIL der Dateiname für die Suche und das Finden unerlässlich ist.

 

Auch dazu hatte Wolfgang bereits in seiner ersten Antwort eine Lösung vorgschlagen: Speicher den letzten Dateinamen ab, mit dem eine PDF-Datei erstellt wurde. Dann kannst du sie auch bei Änderung der Namens-Eigenschaften noch löschen.

Zu deinem letzten Satz: Wer verbietet dir, die ID mit in den Dateinamen aufzunehmen? Wenn du die Datei eindeutig über die ID im Verzeichnis findest, kannst du sie ruhigen Gewissens löschen.
Das mit der ID gefällt mir persönlich besser, da ich nicht so der Fan von unnötiger Datenhaltung bin.

 

Hallo zusammen !

Was lange währt, wird gut. *Smilie

Nachdem ich nun endlich dazu gekommen bin mich wieder mit dieser Thematik zu beschäftigen, bin ich auch zu einem (fast fertigen) Ergebnis gekommen.

Mit dem folgenden Code klappt sowohl das Löschen der bestehenden PDF-Datei, als auch das Erstellen einer neuen PDF-Datei.
Eintzigstes Problem ist gerade nur, dass sich die Prozedur aufhängt, WENN noch kein Speicherpfad im Tabellenfeld steht, dieses also LEER ist.
Es soll also in diesem Fall nix gelöscht werden, sondern mit der Prozedur fortgefahren werden ... wie stelle ich das noch an ?


Code:

 

Leider zeigst du nicht, an welcher Stelle der Cursor stehen bleibt. So mal aus dem Bauch heraus:
Code:

 

Danke für Deine Antwort.

Also er bleibt in der Zeile "If Dir([Speicherpfad]) "" Then" hängen.

Mit Deinem Vorschlag bleibt er ebenso hängenmit dem Hinweis: "Laufzeitfehler 13: Typen unverträglich"

 

Hallo,

Dann muss eben eine Prüfung auf NULL erfolgen - in dem Fall auf die Stringvariable:

Code:

btw - Speicherpfad wurde nicht deklariert - es empfiehlt sich dringend Option Explicit einzuschalten und damit die Variablendeklaration zu erzwingen. Zudem sollten "sprechende" Bezeichner vergeben werden - Befehl258 hilft bei Fehlersuche oder Überarbeitung des Codes nicht wirklich. Und dann solltest du dir eine Liste mit reservierten Wörtern besorgen und diese in Bezeichnern vermeiden - ich denke Filter könnte zu Ärger führen.

hth

 

Also so funktioniert es nicht ganz.
Für einen neu angelegten Datensatz kann es noch keine Datei geben, somit fliege ich immer wieder aus der Prozedur, mit der ja eigentlich im Folgenden erstellt werden soll.

Es soll wie gesagt in diesem Fall nix gelöscht werden, sondern mit der Prozedur einfach fortgefahren werden.

 

Guten Abend,

gibt's da vielleicht noch 'nen anderen Weg den Fehler zu umgehen bzw. das Problem zu lösen ?

 

Hallo Jens!

Es gibt da mehrere Möglichkeiten:
1. Du vergibst im Form für das Textfeld der Datei den Standardwert "".
Damit steht auf jeden Fall ein gültiger Wert in dem Feld und nie Null.
2. Du vergibst in der Tabelle, die den Dateinamen aufnimmt, den Standardwert "".
Folgen wie unter 1. beschrieben.
3. Ob es sich um einen neuen Datensatz handelt kann man mit
Me.NewRecord = True prüfen.

Wolfgang