I'm accessing a MySQL database via JDBC for mailmerge. The writer document contains fields labeled in German like "Anrede", "Vorname", "Name", "PLZ" etc. These are the exact column labels in the database, and they are also displayed in the database browser (F4). However, mailmerge obviously translates the field names internally, so the fields are not replaced correctly when I select a single row in the DB browser and push the "Data in fields" button. Replacing the fields works well if I manually rename the field references into the English equivalents (like "PLZ" in "zip", for example). This did not occur in the 4.2 series.
Which locale are you using for your mailmerge template ? Or rather, what does LO give as the default locale in the status bar at the bottom of the screen ? When you mention mailmerge, do you mean that you are using the Print facility, rather than the mailmerge menu entry ? A sample db and document template would be useful, especially if this is a locale issue, as otherwise it might be hard to reproduce.
If you can't provide a template and ODB, then please provide step-by-step instructions, otherwise we'll be second guessing what it is that you have done.
Additionally, did you exchange the default Addressbook database for your own db ?
Created attachment 103397 [details] Database browser (opened by F4), not the purely German field labels
Created attachment 103398 [details] "Data in text" dialogue - note the now partly English field labels
The locale according to the status bar is "Deutsch (Deutschland)". I actually created an ODS sheet with the records (quite some time ago with a former version of LO). I then created a database file as a proxy and registered this database as source in LO. I'm trying to use the "Data in fields" ("Daten in Felder" i German) button from the toolbar. When I click the "Data in text" button, I get the dialogue attached as Screenshot2.png. Note how the field labels from the list view in Screenshot1.png (just as defined in the database) differ from the labels in the "Data in text" dialogue.
(In reply to comment #6) > I actually created an ODS sheet with the records (quite some time ago with a > former version of LO). I then created a database file as a proxy and > registered this database as source in LO. Sorry, thats not true. As stated in my original comment, data comes not from an ODS, but from a MySQL database.
I just became aware of a fact that made me change this bug's summary/title. The German field labels are defined in the SQL query string like SELECT field1 AS Feld1, UPPER(field2) AS Feld2, ... What happens is that field labels for fields calculated via a SQL function (e.g., "UPPER(...)") are correctly applied/visible in Writer, but all fields that are just aliased (like field1 in the example given above) are not treated correctly and keep their original names as defined in the original database. Sorry for my misleading original problem description!
Hi, I imagine that your query has been saved in the corresponding ODB file ? When you execute that query there, i.e. within the ODB file, does the UI display the aliases correctly ? Alex
> I imagine that your query has been saved in the corresponding ODB file ? > When you execute that query there, i.e. within the ODB file, does the UI > display the aliases correctly ? Yes, Base displays correct column headers.
Well at least that narrows it down to the mailmerge/Wrtier component
Have you declared the datasource as your address book database under Tools > Exchange Addressbok ?
> Have you declared the datasource as your address book database under Tools > > Exchange Addressbok ? No, I've registered it via the preferences dialogue.
At the moment, I don't have any non-capitalized field names that I could use as an address source. If there is a problem, then it is in the matching of lower case equivalent field names with those provided by the mailmerge field code. Additionally, how are you carrying out your mailmerge ? (you never said) (a) Are you using the Mailmerge menu entry ? or (b) Are you inserting fields via dragndrop into your Writer document, and then printing a form letter ?
Please give precise steps, otherwise we will spend too much time trying to nail this down.
I´ll just jump in because I got a similar question today. Customer uses MAC OS (I don´t know the exact version) and LibreOffice since 3 years. Now he has updated to LibO Version 4.2.6.2 and now all is Mail-merge documents doesn´t work any more. Reason: in former version LibO uses german translated field names - and all mail-merge fields are now fixed to these names. the actual version now uses englisch field-names - so merging is not possible. I added an aktual sceenshot witch may explain the differenz. So the question is: What was changed?
Created attachment 107571 [details] Sceenshot 4.2.6.2 - Fieldnames in English - former in German
Adding self to CC if not already on
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-07-18
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of FDO Message generated on: 2015-09-03