@reporter:
Thank you for your report – unfortunately important information is missing.
May be hints on <http://wiki.documentfoundation.org/BugReport> will help you to find out what information will be useful to reproduce your problem? If you believe that that  is really sophisticated please as for Help on a user mailing list
Please:
- Write a meaningful Summary describing exactly what the problem is
- Attach a test kit with sample document and merge result (not only screenshot) 
- Attach screenshots with comments if you believe that that might explain the 
  problem better than a text comment. Best way is to insert your screenshots
  into a DRAW document and to add comments that explain what you want to show
- Contribute a step by step instruction containing every key press and every 
  mouse click how to reproduce your problem (due to example in Bug 43431)
– if possible contribute an instruction how to create a sample document 
  from the scratch
- add information 
  -- what EXACTLY is unexpected
  -- and WHY do you believe it's unexpected (cite Help or Documentation!)
  -- concerning your PC 
  -- concerning your OS (Version, Distribution, Language)
  -- concerning your LibO version and localization (UI language, Locale setting)
  –- Libo settings that might be related to your problems 
  -- how you launch LibO and how you opened the sample document
  -- everything else crossing your mind after you read linked texts

Even  if you can not provide all demanded information, every little new information might bring the breakthrough.

I recommend to try with a current version.

Created attachment 58352 [details]
The source letter for the merging sample

Created attachment 58353 [details]
sample of merged result.

The two attached files are an exemple.
The first one is the source letter, before the merging. To ease the test, I have used the Bibliography database as data source.
The second one is one result of the merging using the wizard, with the option :Save as separate files (nota, as my computer is set in French, I don't know the exact name of the option)

The result seems unexpeced as:
- The other fields (as page number for exemple) are kept as a field.
- The choice of using a field for the number of page means the author expect to have different number of page and not only one.

@FDF:
Reminder:
all Info except source and result documents still are missing, especially why you expect different behavior. Please contribute!

To the question: Why this behavior is unexpected, there are two reasons, but none obvious.
I haven't seen in the documentation that after merging, the files as number of pages… should remain fields, or should be changed to their data.

However, 
it was the case with the previous LibreOffice release. The change appears only since LibreOffice3.
Other fields continue to remain fields after merging. For exemple the "Page number" field remain a "Page number" Field. It is not logical to have this one still flexible as a field and the total number of page no more flexible as merged as data only.

I don't believe it's a bug. May be different behavior in versions before was a bug that has been fixed? For example, in OOo 3.1.1 "No of pages" showed "118" instead of "2" for 59 biblio-"addresses".

This contents will not change after mailmerge process, so it should become "constant contents, like a date field, the address fields, ... . I am more astonished that the current page filed remains a field 

But indeed, may be that there are inconsistencies and may be incomplete or worrying help texts.

Currently I do not see necessity for quick action. 

@FDF:
I would be great if you could gain more information. If we had a complete list (table) with

Variable ... current behavior ... expected behavior ... because ... Help text (Heading, search string) (as a simple text document attachment here) to get a complete overview? May be we can recognize a pattern.

To Rainer,

My choice in the exemple of biblio database has been unfortunate.
We shouldn't comparde the number of page coming from the database and the number of page of the resulting document.
Having the number of page coming from the database as a static information is normal. It is the purpose of merging docs.
But having the number of page of the resulting document as static is not good as any further change in the pagination of the resulting document won't be taken into account and would lead to mistake. for exemple, if we add a page on the resulting doc, we would have printed "page 3 of 2" whish is a mistake. If this remains dynamic, we would have "page 3 of 3" whish is normal.

I hope to have been clear.

I already see in OOo 2.0 that Page No keeps field, but number of pages becomes static in merged.odt

And indeed, I think that is a Bug.

Steps to reproduce:
1. Open "Merging_test_main_file.odt"
2. Menu 'Tools -> Mailmerge Wizard - Use Current Document -> <Next> -> Slect
   Document Type "Letter -> <Next>'
3. In 'Select Address List' add biblio Database from
   C:\....\AppData\Roaming\LibreOfficeDev\4\user\database\biblio\biblio.dbf
   or similar
   and select
   <next><next>
   > Mail Merge Document will become created
4. In step 7 "Personalize document": 'Edit individuall document'
   > Document with 40 pages or so will be opened
5. On first page behind text inserg 4 Page breaks with menu 'Insert'
   > Now you have 44 pages or so
6. Check first Document Headings, result:
   Is:               .... page 1/2  ... page 6/2
   Should be:        .... page 1/6  ... page 6/6

Problem: If the resulting document may be edited in Step 7 it can not be excluded that Number or pages will change, and so it's a bug that "Number of Pages" field has become a static number

@Caolán:
Please change  Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf

Dear FDF,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug