Benutzer mit den meisten Antworten
Feldinhalte, die Datumsangaben vor dem 20. JH in einer Acces-DB enthalten, werden - aus welchen Gründen auch immer - in der Serienbrief-Funktion von Word 2013 nicht akzeptiert!

Frage
-
Es existiert offensichtlich eine Einschränkung für Datumsformat-Formatierungsanweisungen! Feldinhalte, die Datumsangaben vor dem 20. JH in einer Acces-DB enthalten, werden - aus welchen Gründen auch immer - in der Serienbrief-Funktion von Word 2013 nicht akzeptiert!
Ergebnis: Künstler Lange, Otto (Prof.) geb. 1879-10-29, 00.00.00 / gest. 19.12.1944 od. je nach gewählter Datenverbindung/Treiber 10/29/1879
Wird die im obigen Bsp. gebrauchte Jahreszahl 1879 in 1979 in der DB geändert, funktioniert die Formatzuweisung über den nicht dokumentierten Schalter (\@dd.MM.yyyy) im Serienbrief-Dokument korrekt:
Künstler Lange, Otto (Prof.) geb. 29.10.1979 / gest. 19.12.1944
Wird die Jahreszahl auf 1779, 1679, 1579 usw. gesetzt, greift die Formatzuweisung nicht und der Feldinhalt im Merge-Field wird im US-englischem Standardformat für Datumsangaben (Standarddatum + Zeit) ausgegeben - unabhängig von der gewählten Sprach- und Tastatureinstellung.
War das nun eine gewollte Entscheidung in der Treiber-Programmierung bei Microsoft oder ist dieses Problem so nicht bekannt?
Wie kann dieses Problem gelöst werden?
Antworten
-
Haben Sie herzlichen Dank für Ihren Lösungsvorschlag. Er enthält den entscheidenden Hinweis - allerdings nicht in der Form, wie beschrieben. Denn, je nachdem, wie der Startpunkt für den Aufruf der Serienbrief-Funktion von Word (Tabelle, Abfrage, Formular oder VB) gewählt ist, unterscheiden sich die Ergebnisse in für mich nicht nachvollziehbarer Weise. Hinter meiner Anfrage stand auch die Absicht ein Verständnis darüber zu gewinnen, warum die oberste Instanz (Sprach- und Gebietsschema-Einstellungen und dem Versprechen zur jeweiligen Anpassung in der Softwarelösung) nicht greift, bzw. wodurch und an welcher Stelle sie außer Kraft gesetzt wird. Denn eins ist klar, die verschiedenen Geltungsbereiche der Werte für Datums-Feldinhalte wurden nach ihrem Verwendungszweck definiert.
Im Bestreben so viel wie möglich von den „hauseigenen Mitteln“ die Access liefert zu profitieren, wollte ich auf „Hilfskonstruktionen“ soweit es geht verzichten und dass, was über den visuellen Entwurf an Hilfsmitteln zur Verfügung steht, entsprechend nutzen.
Nun zur Lösung:
In Tabellen definierte Datums-Felder benötigen in Abfragen die Übergabe ihres Wertes an eine Variable, wenn ihr Geltungsbereich sich in der gewünschten Formatierung auf einen Wert vor 1900 (nach oben liegt die Grenze wohl bei 2030?) beziehen soll. Dies leistet der Format-Befehl bereits im Abfrage-Entwurf, wenn anstatt des Feldnamens die Variable deklariert und angesprochen wird:
… GDatum:Format([Geburtsdatum]) …
wobei das gewünschte Datumsformat im zugehörigen Eigenschaftsfenster festzulegen ist. Eine gesonderte SQL-Abfrage erübrigt sich. Die in der Abfrage erstellte Variable erscheint – wie Sie beschrieben haben – in SQL als:
… ,Format([Geburtsdatum]) AS GDatum, …
Nun ist es egal, welcher Treiber, welcher Startpunkt usw. gewählt wird, der Geltungsbereich vom Jahr 0 an wird außerhalb von Access korrekt wiedergegeben. Also noch einmal Dank.
Alle Antworten
-
Ich würde das Datum bereits in der Access-Abfrage als String formattieren mit Format(Geburtsdatum, "dd.mm.yyyy") und dann im Word-Dokument ein einfaches Textfeld ohne Formattierungsangaben einfügen. So kann man den Schwierigkeiten mit den Treibern aus dem Weg gehen.
Matthias Kläy, Kläy Computing AG
-
Zum besseren Verständnis: Alle Datums-Felder in Tab. und Abfr. in Access wurden von vornherein mit der Eigenschaft Format: "Datum, kurz" und Formatierung: "DD.MM.YYYY" versehen. In Access selbst gab und gibt es keinerlei Darstellungsprobleme. Erst die Übergabe an die od. die Übernahme durch die Word-Funktion "Sendungen" bereitet Schwierigkeiten, sobald der Wert von "1900" unterschritten wird - und das auch erst mit dem Update Ende 2016. Den Problemen mit der Treiberanbindung kann man also so nicht aus dem Wege gehen.
Traurig ist nur der Zustand in den der Nutzers versetzt wird, indem er sich mit den erwiesenermaßen unzulänglichen Lösungsangeboten von Microsoft herumschlagen muss, denn sie sind für die Änderungen im Leistungsumfang der Treiber in ihren verschiedenen Software-Entwicklungsrichtungen verantwortlich. Also - über den Aufwand, der für so eine einfache Aufgabenstellung und Anforderung zu betreiben ist, darf gar nicht erst nachgedacht werden.
-
Ich spreche nicht von den Format-Eigenschaften, sonder von folgendem: Versuche, dem Serienbrief eine Abfrage der Form
Select Künstlername, Format(Geburtsdatum, "dd.mm.yyyy") As GDatum From Künstler
etc. zugrunde zu legen und im Word-Dokument das Feld GDatum ohne Formatanweisung einzufügen.
Gibt es dann das Problem immer noch?
Matthias Kläy, Kläy Computing AG
-
Haben Sie herzlichen Dank für Ihren Lösungsvorschlag. Er enthält den entscheidenden Hinweis - allerdings nicht in der Form, wie beschrieben. Denn, je nachdem, wie der Startpunkt für den Aufruf der Serienbrief-Funktion von Word (Tabelle, Abfrage, Formular oder VB) gewählt ist, unterscheiden sich die Ergebnisse in für mich nicht nachvollziehbarer Weise. Hinter meiner Anfrage stand auch die Absicht ein Verständnis darüber zu gewinnen, warum die oberste Instanz (Sprach- und Gebietsschema-Einstellungen und dem Versprechen zur jeweiligen Anpassung in der Softwarelösung) nicht greift, bzw. wodurch und an welcher Stelle sie außer Kraft gesetzt wird. Denn eins ist klar, die verschiedenen Geltungsbereiche der Werte für Datums-Feldinhalte wurden nach ihrem Verwendungszweck definiert.
Im Bestreben so viel wie möglich von den „hauseigenen Mitteln“ die Access liefert zu profitieren, wollte ich auf „Hilfskonstruktionen“ soweit es geht verzichten und dass, was über den visuellen Entwurf an Hilfsmitteln zur Verfügung steht, entsprechend nutzen.
Nun zur Lösung:
In Tabellen definierte Datums-Felder benötigen in Abfragen die Übergabe ihres Wertes an eine Variable, wenn ihr Geltungsbereich sich in der gewünschten Formatierung auf einen Wert vor 1900 (nach oben liegt die Grenze wohl bei 2030?) beziehen soll. Dies leistet der Format-Befehl bereits im Abfrage-Entwurf, wenn anstatt des Feldnamens die Variable deklariert und angesprochen wird:
… GDatum:Format([Geburtsdatum]) …
wobei das gewünschte Datumsformat im zugehörigen Eigenschaftsfenster festzulegen ist. Eine gesonderte SQL-Abfrage erübrigt sich. Die in der Abfrage erstellte Variable erscheint – wie Sie beschrieben haben – in SQL als:
… ,Format([Geburtsdatum]) AS GDatum, …
Nun ist es egal, welcher Treiber, welcher Startpunkt usw. gewählt wird, der Geltungsbereich vom Jahr 0 an wird außerhalb von Access korrekt wiedergegeben. Also noch einmal Dank.