Automatischer Seriendruck

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Kennen Sie dies „xxx.doc ist ein Seriendruck-Hauptdokument. Word konnte die Datenquelle yyy.mdb nicht finden.“ Oder das: „Fehler! Feld in Datenquelle nicht gefunden!“ Das muss nicht sein. Erledigen Sie Ihren Seriendruck einfach per Code.

Was ist eigentlich Seriendruck

Die meisten Leser wissen, worum es sich beim Seriendruck handelt. Hier aber noch einmal eine kurze Erläuterung:

Beim Seriendruck wird ein Dokument – das so genannte Hauptdokument – unter Zuhilfenahme Felder genannter Platzhalter als Schablone für eine Dokumentenserie mit stets gleichem Aufbau eingerichtet, wobei nur an den Feldplätzen unterschiedliche Inhalte – meist Datensätze aus einer Datenbank – angezeigt werden.

Ein Hauptdokument enthält dabei neben den festen Textinhalten und der Anordnung der Felder auch noch Verbindungsinformationen über die verwendete Datenquelle.

Die Funktion zum Ausführen befindet sich innerhalb der Textverarbeitung und erzeugt auf Basis der Schablone und der Datensätze ein neues Dokument, das die einem Datensatz entsprechenden aufeinander folgenden Textbereiche durch einen Abschnittswechsel (Seitenwechsel oder fortlaufend) trennt.

Das Ergebnis ist eine umfangreiche Datei, die nach dem Ausdruck im Allgemeinen nicht archiviert wird, da sie viel Platz belegt und eigentlich keine relevanten Informationen enthält: Die veränderlichen Daten (Kundenadressen) stehen bereits in der Datenbank, der unveränderliche Text ist immer derselbe.

Wann brauchen Sie Seriendruck

Aus Sicht eines (Datenbank-)Programmierers mit guten Kenntnissen in der Word-Automation eigentlich gar nicht, könnten Sie antworten.

Wenn man Dokumente voll automatisiert ausgeben kann, kann man dasselbe mit einzelnen Dateien, die man genau so verwirft wie die eine große, die der Seriendruck erzeugt, mit einer einfachen Schleife im Code auch erreichen – ganz ohne Seriendruck.

Der häufigste Grund, warum in der Praxis Seriendruck – sogar für einzelne (!) Briefe – verwendet wird, ist in der Regel der Benutzer selbst: Er weiß einfach nicht, wie man die Daten sonst von Access oder Excel nach Word bekommt.

Da die meisten Seriendrucke von Benutzern ohne Programmierkenntnisse eingerichtet werden, ist das auch wenig verwunderlich.

Es gibt allerdings auch für denjenigen, der sich mit der Dokumenterzeugung per Code vertraut gemacht hat, zwei gute Gründe, sich des Seriendrucks anzunehmen.

Erstens: Der Benutzer soll zum Beispiel ein Rundschreiben mit einem frei zu entwerfenden Text verfassen und dazu eine vorhandene, mit Textmarken versehene Briefvorlage benutzen. Zwischen dem programmatischen Ansprechen der Vorlage und dem Ausgeben der Datensätze findet eine Benutzerinteraktion – nämlich das Entwerfen des Rundschreibentextes – statt.

Zweitens: Die gleiche Situation wie zuvor, aber auch der Text kann vollautomatisch eingefügt werden, zum Beispiel durch Textbausteine. Hier brauchten Sie als Programmierer eigentlich keinen Seriendruck. Aber: Es ist herrlich bequem!

Grundlegender Aufbau

Sie werden daher im Folgenden sehen, wie Sie einen kompletten Seriendruck mittels Code durchführen.

Dazu sind kurz zusammengefasst die gleichen Schritte wie von Hand notwendig:

  • Datenquelle festlegen
  • Seriendruckfelder einfügen
  • Dokument als Hauptdokument festlegen
  • Freitext, um die Felder einzufügen, gegebenenfalls manuell durch Benutzer
  • Ausführung des Seriendrucks, gegebenenfalls manuell durch Benutzer

Es ist grundsätzlich nicht empfehlenswert, fertige Vorlagen mit Seriendruckinformationen anzulegen. Man kann recht problemlos ein Standard-Word-Dokument (also ohne Seriendruckeigenschaft) mittels Code bei Bedarf zu einem Seriendruckhauptdokument machen.

Die Vorteile liegen auf der Hand: Man pflegt zum Beispiel nur eine Vorlage Brief.doc, die ja unter Umständen an ein verändertes Corporate Design anzupassen ist, statt, wie oft im Büroalltag zu beobachten, eine ganze Herde davon, die da heißen Einzelbrief.doc, SerienbriefMitglieder.doc, SerienbriefKunden.doc und so weiter. Redundanz ist nicht nur bei den Nutzdaten von übel.

Der Datenaustausch

Es gibt drei Schnittstellen, über die der Datenaustausch stattfinden kann: DDE, ODBC und OleDB. Welche Schnittstelle angesprochen wird, erkennt Word am Connection-String.

Zur Schnittstellenauswahl sollten Sie Folgendes wissen: In alten Word-Versionen (bis einschließlich 2000) ist DDE Standard und ODBC als Alternative möglich. Ab Word XP ist das neue OleDB verfügbar und dort auch Standard. Ein Seriendruck-Dokument, das mit OleDB erstellt wurde, zum Beispiel manuell mit XP, wird von älteren Word-Versionen überhaupt nicht als gültiges Seriendruckdokument erkannt.

Die DDE-Schnittstelle sollten Sie gar nicht verwenden. DDE ist veraltet, langsam und problembehaftet. DDE öffnet die Datenquelle beim Aufruf erneut, auch wenn sie schon offen ist, was bei Access zu Sperrkonflikten führen kann.

Die ODBC-Schnittstelle ist brauchbar und daher bei Word bis zur Version 2000 das Mittel der Wahl.

Die ab Office XP verfügbare OleDB-Schittstelle ist ebenfalls recht zuverlässig. Sie ist stabil und problemlos, allerdings etwas langsamer als ODBC. Bei sehr umfangreichen Seriendrucken kann Letzteres also noch als Alternative zu OleDB gelten.

Kurz und gut: Wenn der Code auch mit alten Word-Versionen laufen soll oder Performance-Probleme auftreten, sollten Sie ODBC verwenden, sonst OleDB.

Probleme mit Datentypen vermeiden

Beim ODBC-Seriendruck gibt es jedoch bedauerlicherweise einige kleinere ärgernisse. Abhängig vom Datentyp und von den Ländereinstellungen kann in Word vor allem bei Währungen oder Zeitdaten einiger Unfug vorkommen.

Sie umgehen alle derartigen Probleme, wenn Sie als Quelle für einen Seriendruck immer eine temporäre Tabelle benutzen, die ausschließlich Textfelder hat, und Datumsangaben, Beträge und ähnliches dort als formatierten String ablegen. Word ist nun mal eine Textverarbeitung und kommt daher auch am besten mit Texten klar.

Außerdem umgehen Sie damit von vornherein benutzerverwirrende Eingabefenster, die nach irgendwelchen Parametern fragen.

Ein Beispiel für die Verwendung einer temporären Tabelle: Sie wollen drei Felder KundeName (Text), AuftragsDatum (Datum/Uhrzeit), Betrag (Währung) ausgeben. Die Temporärtabelle sollte dafür drei Felder vom Typ Text aufweisen, die Sie aus den Produktivtabellen wie folgt befüllen:

Dim SQL As String
SQL = "DELETE FROM ttmpSeriendruck"
CurrentDb.Execute SQL
SQL = "INSERT INTO ttmpSeriendruck( KundeName, AuftragsDatum, Betrag ) " & _
 "SELECT KundeName, " & _
 "Format$(AuftragsDatum, ''dd.MM.yyyy')," & _
 "Format$(Betrag, ''#,##0.00 €')"
CurrentDb.Execute SQL

Das Feld KundeName ist als Text harmlos. Die konfliktträchtigen Felder Auftragsdatum und Betrag enthalten in der Temporärtabelle jetzt einen ebenso harmlosen Text, zum Beispiel die Strings 04.05.2007 und 2.345,69.

Es liegen hier also keine Zahlen, deren Aussehen über Formate gesteuert wird, mehr vor, sondern tatsächlich genau die Textzeichen wie angezeigt.

Mit diesem Vorgehen gibt es keinerlei Probleme in ODBC, da nur reiner Text übertragen wird, und Sie sind auch bei OleDB in jedem Fall auf der sicheren Seite.

Eigenheiten von Word

Zwei Fallstricke verdienen an dieser Stelle noch Erwähnung, damit sie nicht zur Fußangel werden:

Sie müssen innerhalb der Seriendruckfunktionalität einen SQL-String zusammenbauen, der von Word ausgeführt wird. Bei dem eben vorgeschlagenen Vorgehen wird dieser regelmäßig einfach nur lauten:

SELECT * FROM [ttmpSeriendruck]

Achten Sie auf die eckigen Klammern. Der folgende ANSI-konforme Ausdruck wird nicht ausgeführt:

SELECT * FROM ttmpSeriendruck

Wenn Sie einmal Makrorekorder-Code zum Seriendruck gesehen haben, dann ist Ihnen vielleicht folgende Syntax aufgefallen:

SELECT * FROM 'ttmpSeriendruck'

Die schrägen Hochkommata (ANSI 96) meint Word bitterernst. Wer hier nichts oder ein einfaches Hochkomma (‚) verwendet, wird mit völlig nichts sagenden Fehlermeldungen abgespeist, die mit der Ursache des Problems nichts zu tun haben.

Die einzige ästhetisch befriedigende Alternative zu der Abstrusität ANSI 96, die vermutlich auf mangelhafte SQL-Kenntnisse eines Word-Programmierers in den späten 80er Jahren zurückgeht, sind die eckigen Klammern.

Wenn man mit der Execute-Methode eine Ausgabe aller Briefe in ein neues Dokument vornimmt, wird man auf dieses Dokument auch im Code zugreifen wollen. Jeder Klassenprogrammierer hätte daher Execute als Funktion implementiert, die einen Verweis auf das neue Dokument zurückgibt. Nicht so die Word-Programmierer! Die haben tatsächlich eine Sub verwendet, wodurch das neue Dokument haltlos in der binären Luft hängt.

Wenn man direkt nach Execute einen Verweis auf Documents(1) holt, stehen die Chancen, damit das neue Dokument erwischt zu haben, erfahrungsgemäß aber immerhin gut genug, dass Sie in den nächsten zwanzig Jahren keinen Fehler bekommen werden.

Die Verbindung programmieren

Der Code zum Gesagten sieht anhand eines Beispiels dann wie in Listing 1, Abschnitt [1] aus.

Listing 1: Herstellen der Verbindung zu Word

Dim wdApp As Word.Application [1]
Dim wdDoc As Word.Document
Dim wdDocSDAusgabe As Word.Document
Dim wdRng As Word.Range
Dim wdMerge As Word.MailMerge
Dim wdMfd As Word.MailMergeField
Dim wdFld As Word.Field
Dim tConnectionString As String
Dim tSourceDatabase As String
Dim tSourceTable As String
Set wdDoc = <Verweis auf Briefvorlage nach einer der im Artikel 
 "Rechnungen in Word schreiben" in Heft 4, August 2007 
 erläuterten Methoden>
Set wdMerge = wdDoc.MailMerge
tSourceDatabase = CurrentDb.Name [2]
''(oder auch "Pfad\und\Name.mdb")
tSourceTable = "ttmpSeriendruck"
''(Tabellen- oder Abfragename)
''Oledb
tConnectionString = _
 "Provider=Microsoft.Jet.OLEDB.4.0;" & _
 "Password="""";" & _
 "User ID=Admin;" & _
 "Data Source=" & tSourceDatabase & ";" & _
 "Mode=Read;" & _
 "Extended Properties="""";"
wdMerge.OpenDataSource _
 Name:=tSourceDatabase, _
 LinkToSource:=True, _
 Connection:=tConnectionString, _
 SQLStatement:= _
 "SELECT * FROM [" & tSourceTable & "]", _
 SQLStatement1:="", _
 SubType:=wdMergeSubTypeAccess

Mit der letzten Zeile dieses Abschnitts ist im Grunde noch nichts passiert. wdMerge enthält jetzt einen Verweis auf die hypothetische Seriendruckfunktionalität von wdDoc, obwohl dieses jetzt noch kein Seriendruckdokument ist.

Weiter geht es mit den folgenden Zeilen; die dort verwendeten Namen und der Connection-String sind gegebenenfalls entsprechend Ihrer Anwendung anzupassen, zum Beispiel der Provider, wenn auf andere Datenbankformate zugegriffen werden soll.

Die Syntax entspricht üblichen ADO-Connection-Strings (s. Listing 1, Abschnitt [2]).

Durch den ersten Code-Block in Listing 2 wird das Dokument zum Seriendruckdokument und ist mit der angegebenen Quelle verknüpft. Im gleichen Listing sehen Sie den notwendigen Code für die ODBC– und DDE-Schnittstelle.

Listing 2: Verbindungsdaten mit ODBC/DDE vorbereiten

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo

Schreibe einen Kommentar