Word Serienbriefdatei mit Delphi einlesen

[Smiley]

Ich möchte mit Delphi Eine Word Serienbriefdatenquelle einlesen und die Felder in eine eigene datenbank schreiben.
Gibt es irgend was einfaches über OLE oder über eine Konvertierung.
Versuche es gerade als Textdatei aus Word abzuspeichern, da bekomme ich das Problem, dass die Felder beschnitten werden, da die Tabelle zu breit ist. Wenn ich die Spalten breiter mache, kann ich die hinteren Spalten nicht mehr vergrößern, da word da eine Beschränkung drin hat.
Oder soll ich es über RTF machen.
Wie kann ich das RTF-Dokument dann ansprechen, um die Felder aus den Spalten herauszubekommen ?
Hab mit den RTF-Komponenten noch nicht gearbeitet.

[Hansa]

Ja, wo kommt denn die "Word-Serienbriefdatenquelle" überhaupt her ? Ich brauche doch kein Word, um eine vorhandene Datenquelle im Textformat in eine Datenbank zu schreiben. 8)

[Smiley]

Das Problem ist, dass zur zeit die Serienbriefe mit Word und einer Wordserienbriefdatenquelle (Wordtabelle) geschrieben werden.
Leider ist die Datenquelle immer schwerer zu verwalten und das Word stürzt bei den serienbriefen immer mal ab oder Der Drucker bleibt hängen und es kommt nur noch Müll raus.
Daher wollte ich die Daten in delphi übernehmen und in eine ADO-Datenbank schreiben.
Die kann ich dann mit einem Programm verwalten und die selektierten Daten dann mit OLE in Word drucken.
Damit hoffe ich die ständigen Probleme beim Drucken beseitigen zu können und die Daten können dann auch besser vorher aufbereitet werden. z.B. kann die Anrede in den Briefen aufgrund von Grunddaten wie männlich/weiblich, Einzel- oder Mehrfachansrache und sonstiges über das Programm gesteuert werden und muss nicht für jede Adresse in allen Varianten in der Datenbank abgelegt werden..

[Hansa]

Zitat:

Zitat von Smiley

..Leider ist die Datenquelle immer schwerer zu verwalten und das Word stürzt bei den serienbriefen immer mal ab oder Der Drucker bleibt hängen und es kommt nur noch Müll raus.
..

Ja verdammt nochmal. :mrgreen: Wo zum Teufel kommt denn die Datenquelle jetzt her ? Der Müll der da kommt, kann auch aus dem Ausland kommen. Also : Zeichensätze. Solange die Datenquelle nicht bekannt ist, wird dir schwerlich einer helfen können. Word tut fast nichts zur Sache. Das ist fast egal.

[Smiley]

Wie ich schon sagte die Datenquelle ist eine "Wordserienbriefdatenquelle" erstellt in Word97 mit 5 fingern geschrieben und als Worddatenquelle abgelegt mit dem namen Adressen.doc.
Ist das jetzt deutlich genug.
Wenn man sie mit Word öffnet hat man eine Wordtabelle vor sich in der die Adressen und andere Informationen Zeilenweise eingetragen sind.
Das ist meine Ausgangsdatenquelle die ich in Delphi einlesen möchte.

[Hansa]

Zitat:

Zitat von Smiley

Wie ich schon sagte die Datenquelle ist eine "Wordserienbriefdatenquelle" erstellt in Word97 mit 5 fingern geschrieben und als Worddatenquelle abgelegt mit dem namen Adressen.doc...Das ist meine Ausgangsdatenquelle die ich in Delphi einlesen möchte.

Aha. Das ist alles ? Dann kann man Dir ja leicht helfen. Speichere diese Datenquelle nicht im Word-Format ab, sondern als "Nur Text" oder "Text mit Zeilenumbruch". Weiß jetzt nicht mehr genau, notfalls bzw. sowieso alles testen. Diese Text-Datenquelle sollte bereits von Word vorformatiert sein. Und zwar mit festen Feldlängen für die Datenquellen. Dann interessiert der eigentliche Inhalt nämlich nicht.

Nun muß man diese Datenquelle in Felder für die DB aufteilen. Einfach mit z.B. :

Delphi-Quellcode:

Feld := copy (zeile,1,10);

Diese Felder übergibt man dann mit FieldByName an die DB und das wars dann zumindest im Groben.

Da in letzter Zeit sehr viele Vorschläge bezüglich CSV gemacht wurden, bzw. kann das Erstellen der Datenquelle nicht beeinflußt werden und gibt eine CSV Datenquelle vor, dann wird das alles zwar unnötigerweise etwas komplizierter, aber dann ginge das so : Den vorhandenen Text nach den CSV Trennzeichen durchsuchen und notfalls ersetzen. Muß das Trennzeichen definitiv als Identifier für Namen usw. dienen und darf deshalb nicht ersetzt werden, dann muß man das in "" oder was anderes einschließen. Dann dürfen die " natürlich nicht als Trennzeichen definiert werden. Sogar in diesem Fall müßte man nur die Datenquelle Zeichen für Zeichen bearbeiten. 8)

[Smiley]

Das mit der Textdatei hab ich ja als erstes probiert siehe ersten post,

Zitat:

Versuche es gerade als Textdatei aus Word abzuspeichern, da bekomme ich das Problem, dass die Felder beschnitten werden, da die Tabelle zu breit ist. Wenn ich die Spalten breiter mache, kann ich die hinteren Spalten nicht mehr vergrößern, da word da eine Beschränkung drin hat.

dafür hab ich auch schon das Programm zum einlesen.
Dummerweise lässt Word einige Teile der Daten einfach weg.
Es sieht fast so aus als sei die Datenquelle einfach defekt.
Wenn ich die Datenquelle in XML abspeichere und mit Excel versuche sie als XML zu importieren, dann kommt auch eine Fehlermeldung.

Soweit so gut, es ging mir nur darum, zu erfahren, ob es eine Elegantere Art als die über eine Textdatei gibt.
Mit dem einlesen von Textdaten und deren Verarbeitung kenne ich mich ausreichend gut aus, aber ich frage mich halt immer warum soll ich ständig das Rad neu erfinden, solche Probleme hatten doch schon viele und ich wundere mich warum es dafür keine Vorlagen gibt.

Wenn ich die Datei in Excel hereinbekommen hätte, dann hätte ich sie als CSV Datei abgespeichert. Zum einlesen von CSV Dateien gibt es doch schon fertige Routinen. War da nicht etwas in den JEDI-Tools ?

Da also keine anderen Ideen als das einlesen über Textdatei kommen ist das Thema dann erst mal erledigt, es sei denn jemand hat noch eine geniale Idee wie man über Wordautomation oder sowas das hinbekommen kann.

------------- Der Weg ist das Ziel -----------

[Hansa]

Auch XML sind Textdateien. Normale Textdateien sind nur eben einfacher aufgebaut, als XML-Dateien. Auch CSV-Dateien sind stinknormale Textdateien. Sie haben eben nur unterschiedliche Zeilenlängen, was für Überprüfungszwecke usw. sehr hinderlich ist. Das Trennzeichen erfordert meistens zusätzlich noch eine Spezialbehandlung. Habs langsam oft genug gesagt. Du kommst also so oder so nicht drum rum. Was Du machst, ist nicht etwa das Rad neu zu erfinden, sondern ein Spezialrad zu suchen, das keiner hat und keiner braucht, um damit dasselbe zu tun, wie die, die schon lange weggefahren und wohl schon im Ziel sind. Mit Deinem Rad fährst du nun immer noch nicht, sondern eierst immer noch in der Gegend rum. :mrgreen: