1. On a samba share on another computer on your local network: (a) Create a calc doc (spreadsheet). (b) Put in columns c1 c2 c3 in first row, with data 1, 2, 3 in second row. 2. On your local computer, create a database file connected tothe calc doc: (a) use existing database, type Spreadsheet (b) navigate to the calc doc you create above. (c) save the .odb file in your local directory (you can't save it on the samba share --- LO will refuse to write there so you don't have much choice here) 3. Create a writer doc. (a) put in some "blah blah blah" fixed text (b) open up the "data sources" and select the database you created in (2) above. (c) drag some fields from the db into the writer doc. You can put in columns c1, c2, c3 for example. When you do this, they look like "<c1>", where all the text has a dark grey background and the whole thing is a solid field entity (you can't put your cursor between the "c" and the "1" for example. 4. Print the writer doc. (a) LO will notice that there are form fields and ask if you want to print a form letter - say yes. (b) choose Print to File, one file per doc, use column 1 as the doc name generator. 5. You will find that you have one new doc (corresponding to the one record in the spreadsheet) in your Documents folder... and it is correctly printed. 6. Save the writer doc. This will save it on the samba share. 7. Reopen the writer doc. It won't have any form fields any more. They will all simply be changed into fixed and editable text with the names of the database fields e.g., "<c1>" ... no longer with dark grey background. Just plain text. What should happen: when I save a doc with database fields, it should save it so that I can reopen it later and print another form letter. This works fine as long as the writer doc is on my local machine.
Hi Francis, Thanks for the clear report. Looking at your steps 6 and 7: could it be different if you save the document already in step 3?? Regards, Cor
Hi Cor I made a new .odt file and saved it on the samba share. I then opened it up again, and added some database fields to it (from a more complex spreadsheet than the one i indicated in the bug report) and then saved the doc. I reopened it and this time the fields were retained. However, I opened up a more complex .doc file (18 pages) which was in the same directory as the .odt mentioned above, and did exactly the same thing with exactly the same complex spreadsheet as in my test above. I added one database field to this doc. I saved it & reopened it -- but the database field was gone and only its character representation remained. F. On Tue, 2013-07-23 at 19:52 +0000, bugzilla-daemon@freedesktop.org wrote: > Cor Nouws changed bug 67207 > What > Removed > Added > CC > > cno@nouenoff.nl > > Comment # 1 on bug 67207 from Cor Nouws > Hi Francis, > > Thanks for the clear report. > Looking at your steps 6 and 7: could it be different if you save the document > already in step 3?? > Regards, > Cor > > ______________________________________________________________________ > You are receiving this mail because: > * You reported the bug.
Hi Francis, Thanks for your additional comment. Pls try to reply in the IssueTracker on the web, not cia the mail. Thus we keep the comments a bit clean :) (In reply to comment #2) > However, I opened up a more complex .doc file (18 pages) which was in > the same directory as the .odt mentioned above, and did exactly the same > thing with exactly the same complex spreadsheet as in my test above. I > added one database field to this doc. I saved it & reopened it -- but > the database field was gone and only its character representation > remained. Now I understand it's 'simply' the issue that in .doc format LibreOffice mail merge fields are not retained. That's all. Has allways been that way. And I really doubt if that can be changed (in any case I always advise people not to save their mail merge master files in .doc :) ) Changing summary and such... Also: should be checked on duplicate issues (I skip that due to time contraints.)
Hi Cor, Sorry for the reply via email; I don't file bug reports very often. Thanks for clarifying that the behaviour is known and taking the time to read the report! To summarize: it's a known issue with .doc compatibility, it won't likely be fixed, and so use .odt instead. Please correct me if I've missed the gist of it. Cheers, F.
(In reply to comment #4) > Sorry for the reply via email; I don't file bug reports very often. No problem! > Thanks for clarifying that the behaviour is known and taking the time to > read the report! > > To summarize: it's a known issue with .doc compatibility, it won't likely be > fixed, and so use .odt instead. Please correct me if I've missed the gist > of it. That's it, indeed. Best, Cor
*** Bug 67488 has been marked as a duplicate of this bug. ***
*** Bug 81042 has been marked as a duplicate of this bug. ***
*** Bug 83451 has been marked as a duplicate of this bug. ***
Adding self to CC if not already on
*** Bug 80845 has been marked as a duplicate of this bug. ***
Changing the summary to make it more generic for saving certain fields WAS FILESAVE saving as .doc replaces the FIELDS in a MAILMERGE document with the "< fieldname >" NEW FILESAVE saving as .DOC or .DOCX replaces MailMerge, User Defined, Input Fields, .. in a document with the "< fieldname >"
*** Bug 68140 has been marked as a duplicate of this bug. ***
*** Bug 95089 has been marked as a duplicate of this bug. ***
*** Bug 100083 has been marked as a duplicate of this bug. ***
Unfortunately, this bug became more "generic" - in a way, that it covers different issues that are better solved separately. For mail merge fields, a patch is in gerrit: https://gerrit.libreoffice.org/45193 I don't plan working on other field types ATM.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca6fec87e0ebc32a748f9f44143e6336b008399e tdf#67207: export MERGEDIELD to DOCX and DOC It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I set this bug back to mailmerge only. Now, mailmerge field is there in DOC/DOCX. But, form letter print for those saved DOC and DOCX is not possible, it says: The data source "" was not found. Mike, can you please check?
(In reply to Timur from comment #17) > But, form letter print for those saved DOC and DOCX is not possible, it > says: The data source "" was not found. Yes, as the commit message says, > This does not export data source information yet
Dear Mike Kaganski, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/071c3309260aeae22f464d26bfa56a747f6a02cb%5E%21 tdf#67207 DOCX mail merge: fix export/import of database fields It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
As Mike mentioned, this bug was quite generic, so it's better to solve the related remaining problems separately. The original issue was fixed by Mike and my patches using the open standard DOCX format, so I close this issue. Maybe it's worth to file or reopen a DOC issue, but it would be more useful to support of the original DOCX mailMerge fields and their mapping, creating a working database connection automatically in LibO, too. I'm attaching a test document for it for a future issue.
Created attachment 151081 [details] DOCX mail merge document from Excel, connected to an XLSX data source
(In reply to László Németh from comment #21) > Maybe it's worth to file or reopen a DOC issue,.. Done so with bug 81042