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 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

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 >"

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.

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