CSV-Datei für Word-Seriendruck

[jr]

Hallo zusammen,

das ist wohl eigentlich kein echtes Notes-Problem, aber ich denke es passt hier ganz gut rein. Ich erzeuge aus Notes-Daten eine CSV-Datei, mit der ich dann in Word Seriendruckdokumente erzeuge. Das funktioniert seit Jahren einwandfrei, aber in der letzten Zeit kommen immer wieder CSV-Dateien zustande, die Word partout nicht importieren will.

Den Grund hab ich mittlerweile gefunden, es sind die Anführungszeichen. Die Benutzer kopieren Texte aus einem Word-Dokument in ein Notes-Feld und irgend wann wird dieser Text wieder in der CSV-Datei benutzt.

Beispieltext:        Der Text ist "manchmal" in Hochkommata geschrieben.

In der CSV-Datei muss dass dann so aussehen:

...; "Der Text ist ""manchmal"" in Hochkommata geschrieben"; ...

Damit funktioniert der Seriendruck in Word. Aber von " gibt es gefühlte 2 Millionen verschiedene Varianten. Immer wieder tauchen neue auf. (Neues Word - neue Hochkommata??? Keine Ahnung). Bisher hab ich folgende ausgemacht:

Chr(34)     Das Standard Hochkomma (Shift 2), hatte ich von Anfang an ersetzt
Chr(147)   Kommt wohl aus einem Word-Dokument (Anführungszeichen unten)
Chr(148)   Dito, aber oben
Chr(132)   keine Anhnung wo das herkommt, ist heute neu aufgetaucht

Ich ersetze alle mit csvText = ReplaceSubstring(csvText, c, c+c) und dann klappt es auch. Aber ich möchte nicht immer wieder Anrufe von meinen Kunden bekommen, dass ein Export nicht funktioniert hat.

Weiß jemand, welche Zeichen beim CSV-Export noch Probleme bereiten und welche ich noch beachten muss?

Auch wäre ich dankbar, wenn Ihr mich noch auf andere Fallstricke beim CSV-Export aufmerksam machen könntet.

Viele Grüße,

Joachim

[Axel]

Welche Zeichen beim csv-Export noch Probleme bereiten und welche Fallstricke noch lauern kann ich dir aus dem Hut im moment nicht sagen. Aber ich bin vor einiger Zeit dazu übergegangen Steuerdateien für Serienbriefe in Word als Word-Dokument zu generieren. Ich erstelle ein leeres Dokument und füge dort eine Tabelle ein. In dieser Tabelle sind in der ersten Zeile die Bezeichnungen (sie dienen auch als Seriendruckfelder) enthalten und in den folgenden Zeilen sind dann die Daten enthalten.

Vielleicht ist das eine Alternative für dich.

Axel

[jr]

Hallo Axel,

danke für die Antwort. Wenn Du das als Tabelle machst, dann müssen die Texte nicht mehr in Hochkomma eingeschlossen werden, oder? Das heißt, das oben beschriebene Problem würde gar nicht erst auftauchen.

Hmmm, klingt interessant. Die Word-Tabelle wird per Notes generiert und dann direkt mit der Serienbriefvorlage gemischt. Habe ich so noch nicht gemacht, sollte aber relativ einfach sein.

Alternativ könnte ich das ja auch mit Excel direkt machen. Wer Word hat, der hat in der Regel auch Excel. Da würde das Problem ebenfalls wegfallen, aber es dauert halt länger, weil zuerst Excel gestartet werden muss, auch wenn das ganze im Hintergrund passiert. Bei Deiner Lösung muss Word ja sowieso gestartet werden, würde also die Performance nicht beeinträchtigen.

Die Applikation wird derzeit mit etwa hundert Word-Vorlagen benutzt. Und da ich den Benutzern nicht zumuten kann, jedesmal die benutzten Seriendruckfelder in einer Liste zu hinterlegen, gebe ich einfach alle möglichen Seriendruckfelder aus. Dadurch komme ich aber mittlerweile auf fast 300 Spalten. Performancemäßig ist das kein Problem, aber schafft das Word noch? Eine Tabelle mit 300 Spalten?

Ich glaube, ich muss das mal probieren. Aber diese Woche schaffe ich das nicht mehr.


Gruß,

Joachim

[Axel]

Wenn Du das als Tabelle machst, dann müssen die Texte nicht mehr in Hochkomma eingeschlossen werden, oder? Das heißt, das oben beschriebene Problem würde gar nicht erst auftauchen.

Richtig

Hmmm, klingt interessant. Die Word-Tabelle wird per Notes generiert und dann direkt mit der Serienbriefvorlage gemischt. Habe ich so noch nicht gemacht, sollte aber relativ einfach sein.

Ist es auch.

Die Applikation wird derzeit mit etwa hundert Word-Vorlagen benutzt. Und da ich den Benutzern nicht zumuten kann, jedesmal die benutzten Seriendruckfelder in einer Liste zu hinterlegen, gebe ich einfach alle möglichen Seriendruckfelder aus. Dadurch komme ich aber mittlerweile auf fast 300 Spalten. Performancemäßig ist das kein Problem, aber schafft das Word noch? Eine Tabelle mit 300 Spalten?

Das wird wahrscheinlich ein Problem werden. Bei Word 2003 ist bei 63 Spalten Schluss.

Axel

[jr]

Hallo,

schade, bei 63 Spalten kommt das dann leider nicht in Frage. Der Kunde hat noch 2003 im Einsatz. Ich versuchs hier mal mit Office 2007, ob sich da die Spaltenzahl verändert hat. Ich sag bescheid, wenn ich es ausprobiert habe.

Gruß,

Joachim

[Axel]

Die Applikation wird derzeit mit etwa hundert Word-Vorlagen benutzt. Und da ich den Benutzern nicht zumuten kann, jedesmal die benutzten Seriendruckfelder in einer Liste zu hinterlegen, gebe ich einfach alle möglichen Seriendruckfelder aus.

Der Weg ist aber nicht unbedingt der idealste.

In so einem Fall würde ich das Ganze konfigurierbar halten, d.h. über Konfigurationsdokumente. Ich würde pro Vorlage ein Dokument erstellen, die in einem RTF-Feld die Vorlage selbst und in einem weiteren Feld die Namen aller, für den Seriendruck in Frage Felder hinterlegen.

So hast du den Aufwand einmal und die Anwendung wird performanter.

Axel

[jr]

Hallo Axel,

habs jetzt mal mit Word 2007 versucht. Auch da sind nur maximal 63 Spalten möglich - schade.

Du hast natürlich recht damit, dass 300 Spalten nicht unbedingt optimal sind. Aber ich sehe da keine andere Lösung. Die meisten Vorlagen liegen schon in Konfiguratonsdokumenten und diese haben auch ein zusätzliches Feld, in das ich normalerweise die Felder eintrage oder beim Excel-Export direkte Zellenzuweisungen in der Form A5 := @Now reinschreiben kann. Das kann ich aber nur machen, wenn ich die Vorlagen selbst erstelle, weil ich dann genau weiß, welche Felder ich benutze. Da die Anwender aber beliebige Seriendruckvorlagen erstellen können, kann ich denen nicht zumuten, danach noch eine Liste mit den Feldern anzulegen.

Vielleicht kurz eine Erläuterung, wie das bei mir funktioniert:

In einem Konfigurationsdokument wird eine Reihe von Seriendruckfeldern definiert. Das sieht dann z. B. so aus:

Code

Heute       := @Today                              <-- @Formeln
Absender    := @Name([CN]; @UserName)
Empfänger   := sSenderName                         <-- direkte Feldwerte
Hallo       := "Hallo " + Empfänger                <-- Zugriff auf den bereits berechneten Spaltenwert "Empfänger"
Adresse     := @Implode(sSenderAddress; @Char(10)) <-- Mehrfachwert durch Zeilenschaltung getrennt
Preis«1..9» := val := nPrice«x»; @If(val = ""; ""; @Text(val; "C,2"))   <-- Das gibt gleich 9 Spalten!
... usw.

Wie gesagt, das macht dann so um die 300 Spalten. Die Anwender kennen natürlich nur die Seriendrucknamen, also Heute, Absender, Empfänger, Preis1, usw. und können diese beliebig in Ihren Seriendruckdokumenten benutzen. Außerdem hab ich noch einen Assistenten geschrieben, mit dem Sie sich Seriendruckdokumente erstellen können und alle möglichen Feldnamen werden automatisch mit Werten zur Verfügung gestellt.

Die Geschwindigkeit ist kein Problem, die 300 Werte stehen in null komma nix in der Datei. Die Zeit dafür ist minimal und der Word-Aufruf dauert um ein vielfaches länger als die CSV-Erstellung. Bis die Word-Datei fertig ist dauert es zwischen 5 und 10 Sekunden, ich denke, das ist akzeptabel.

Der Benutzer kann also jedes beliebige Feld einsetzen ohne sich darüber Gedanken machen zu müssen, ob dieses Feld noch irgend wie definiert werden muss.

Nochmals vielen Dank für Deine Hilfe,

Joachim