Bug 101841 - MAILMERGE: First Record Incorrect When Printing Selected Records to File
Summary: MAILMERGE: First Record Incorrect When Printing Selected Records to File
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.0.4 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.3.0 target:5.2.5
Keywords:
: 102061 (view as bug list)
Depends on:
Blocks: Mail-Merge 102061
  Show dependency treegraph
 
Reported: 2016-09-01 11:09 UTC by JAG220
Modified: 2017-02-07 06:38 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of printing status dialog (28.48 KB, image/jpeg)
2016-09-01 11:09 UTC, JAG220
Details
Sample database to test bug (14.28 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-09-29 10:53 UTC, JAG220
Details

Note You need to log in before you can comment on or make changes to this bug.
Description JAG220 2016-09-01 11:09:45 UTC
Created attachment 127109 [details]
Screenshot of printing status dialog

Printing selected records to file results in a document with the first record merged being the very first record in the database.
Additionally, the printing status dialog is also wrong; it shows the page total as if it was merging every single record in the database (see attached screenshot). Though other than the incorrect first record, it merges everything else fine (ie. it does not merge every single record). This may be linked to the incorrect first record retrieval.

eg. If I select 6 records which are midway through a large database, the first record retrieved is incorrectly always the very first record. The next 5 records are correct. When expecting a 1 page document, the printing dialog shows "Progress: 1 of 387".

This is only a problem when printing to file; merging direct to a printer works as it should.
None of these problems are an issue in 5.1.5.2.

I hope it was okay to mark the bug as critical—merging to a file/document is a must that I use all the time.
Comment 1 Buovjaga 2016-09-22 20:14:37 UTC
There has been a lot of work put into mail-merge recently and I'm not sure, if all of it is in 5.2.0.

You could try with a fresh dev build: http://dev-builds.libreoffice.org/daily/master/Win-x86@42/current/
It installs in parallel.
Comment 2 Adolfo Jayme Barrientos 2016-09-26 06:54:45 UTC
Commit 260cd3aeea2d02507dd131ee2028c4f48f7562f8 is related to this issue
Comment 3 Xisco Faulí 2016-09-26 10:32:59 UTC
Is it a regression introduced by the commit you mentioned in comment 2?
Comment 4 MrTheV 2016-09-26 20:54:34 UTC
Just tried with LO Writer, Version: 5.3.0.0.alpha0+
Build ID: 423c67150631545b512e40d8c1e716b3ba8b6569
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-25_23:57:54

The issue is still there (same issue in 5.2.1)

It does not have any impact if you select some records or enter the boundaries in the "From: .. To:" dialog.

Note that if you select two records, the second is correctly printed, but the first one is always built from the first record in the base.

Note also that some attempts that you do AFTER the first printing are printed correctly, whatever the records you select to generate the printing. ANd this can even work after you closed and opened LO Writer again.

The file name was based on a field in the db (an ods file), and the file type was pdf, for all my tests.
Comment 5 Jan-Marek Glogowski 2016-09-28 15:26:20 UTC
(In reply to Xisco Faulí from comment #3)
> Is it a regression introduced by the commit you mentioned in comment 2?

No. This patch should fix the accounting part of the bug report.

But I'm unable to reproduce the bug on Linux. Probably it's a Windows only bug, but - AFAIK - mail merge doesn't use platform dependent code.

My steps were:
 * New Writer doc
 * Ctrl+Shift+F4, Biblography => Table => biblio
 * Drag identifier header into document and save it
 * Ctrl+P => Create mail merge
 * Select rows. Print to single document or a PDF printer
 * Result is as expected.

My version is master from 2016-09-20 with some additional KDE4 patches.

Please provide your steps to reproduce the bug, probably using an example document based on the bibliography DB.
Comment 6 JAG220 2016-09-29 06:44:45 UTC
Tested using the biblio database as suggested (used some "Next Record" entries as well) and bug was NOT present.

Bug IS present when using my own odb database. Some info:
  * Database is based on/linked to an odt spreadsheet.
  * Spreadsheet is 14 columns (fields) by a couple hundred rows (records) large
    (i.e. quite a lot of fields and entries).
  * Document itself merges multiple records of a number of fields on the one page.
  * Database was set up earlier this year, which would have been 5.1.0 or 5.1.1
    if that makes a difference. 

Not sure what else I can add except to say try creating your own database based on a spreadsheet to see if the bug is reproduced.
Comment 7 JAG220 2016-09-29 06:47:37 UTC
Forgot to mention I've still been using the 5.2.1.2 release version in my tests.
Comment 8 Buovjaga 2016-09-29 09:16:47 UTC
(In reply to skylinegtr from comment #6)
> Not sure what else I can add except to say try creating your own database
> based on a spreadsheet to see if the bug is reproduced.

You have to create an example database and attach it for this to move forward.
Comment 9 JAG220 2016-09-29 10:53:45 UTC
Created attachment 127721 [details]
Sample database to test bug

I've done some more testing, creating a very simple database and found out that if the spreadsheet has 42 or more records, the bug is present.
That might explain why the biblio database works fine as it contains only a few record entries.

The spreadsheet I used is attached. Register it as a database, mail merge and you should come across the bug.
Afterwards if you remove one record from the spreadsheet, mail merge again, the bug should have disappeared.

Hopefully that's enough to determine what is causing the bug.
Comment 10 Alex Thurgood 2016-09-29 15:49:11 UTC
(In reply to skylinegtr from comment #9)


> I've done some more testing, creating a very simple database and found out
> that if the spreadsheet has 42 or more records, the bug is present.
> That might explain why the biblio database works fine as it contains only a
> few record entries.


This (i.e. the number 42) rings a bell with regard to a bug in the bibliography database handling...if only I could find that one again...
Comment 11 Jan-Marek Glogowski 2016-10-01 11:07:24 UTC
Please attach a test document (odt), which fails for you.

I still can't reproduce the bug, but I'm using master on Linux and currently don't have access to LO 5.2.

I registered your spreadsheet and used the same steps as before inserting both columns in a test document. I selected rows 3-5 and it worked as expected.

Can you try to reproduce the bug using a daily build available at
http://dev-builds.libreoffice.org/daily/master/ ? More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Probably it's already fixed in 5.3.

I won't be able to test this bug with LO 5.2 before 2016-10-11.
Comment 12 JAG220 2016-10-06 03:22:21 UTC
I've finally had the time to test this bug on the latest x86/32 bit daily build (2016-10-05_02.20.01).

The good news is, everything works as expected, even on a large database set. No more incorrect record retrieval or wrong printing status dialog. (I just hope it's not a 64 bit exclusive bug.)

I wonder what the problem is and if it's fixed in the next minor 5.2 release which is due at the end of this month? I'll just keep using this master build for my mail-merging requirements until 5.3 is released which is only a few months away anyway.
Comment 13 Jan-Marek Glogowski 2016-10-06 07:56:02 UTC
Thanks for the test. Now I just need to reproduce it with 5.2 and find and backport the fix... bug 102061 at least confirms it also happens on Linux.
Comment 14 JAG220 2016-10-21 08:43:26 UTC
Short update:

Bug is still present in the new 5.2.2.2 (x64) stable release.
Comment 15 Xisco Faulí 2016-11-02 12:16:44 UTC
Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Changing status to NEW.
Comment 16 JAG220 2016-11-04 01:08:24 UTC
(In reply to Xisco Faulí from comment #15)
> Hello,
> Is this bug fixed?
> If so, could you please close it as RESOLVED FIXED?
> Changing status to NEW.


I just checked the recent 5.2.3 "fresh" release (Win x64) and the bug is still present.
Comment 17 Jan-Marek Glogowski 2016-12-19 12:44:15 UTC
*** Bug 102061 has been marked as a duplicate of this bug. ***
Comment 18 Commit Notification 2017-01-11 22:31:21 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bbb2a2bac5486b9a9b9d7061f058defc11fc447f&h=libreoffice-5-2

tdf#101841 MM correctly account record selections

It will be available in 5.2.5.

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.
Comment 19 JAG220 2017-02-07 06:38:37 UTC
I'm not sure about 5.2.5 but I have installed 5.3.0 (Windows_x64) and this bug has been fixed.

Thanks.