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.
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.
Commit 260cd3aeea2d02507dd131ee2028c4f48f7562f8 is related to this issue
Is it a regression introduced by the commit you mentioned in comment 2?
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.
(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.
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.
Forgot to mention I've still been using the 5.2.1.2 release version in my tests.
(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.
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.
(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...
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.
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.
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.
Short update: Bug is still present in the new 5.2.2.2 (x64) stable release.
Hello, Is this bug fixed? If so, could you please close it as RESOLVED FIXED? Changing status to NEW.
(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.
*** Bug 102061 has been marked as a duplicate of this bug. ***
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.
I'm not sure about 5.2.5 but I have installed 5.3.0 (Windows_x64) and this bug has been fixed. Thanks.