Download it now!
Bug 73025 - MAILMERGE: Database field of type "Any record"
Summary: MAILMERGE: Database field of type "Any record"
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA target:5.2.0
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
Reported: 2013-12-25 08:11 UTC by mishich
Modified: 2019-12-09 17:27 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:

Database file to use in mergemail (2.96 KB, application/vnd.oasis.opendocument.database)
2013-12-29 14:31 UTC, mishich
Text doc i used to test mailmerge fail. (7.83 KB, application/vnd.oasis.opendocument.text)
2013-12-29 14:32 UTC, mishich

Note You need to log in before you can comment on or make changes to this bug.
Description mishich 2013-12-25 08:11:18 UTC
Problem description: due to Help "Only records selected by a multiple selection in the data source view are considered". In fact, all records from dataset are considered. And with strange indexing: record number of first record in dataset is 2, second is 3, and so on...

Steps to reproduce:
1. Insert into text doc database field: Insert - Fields - Other..., Database tab, Type set to "Any record", Record number set to 2
2. Insert into text field(s) of type "Mail merge field" from some dataset 
3. Open data sources: View - Data Sources
4. In data source select two or greater records, start from second or greater
5. Click button "Data to Fields"

Current behavior: The values of first record of dataset are inserted into fields

Expected behavior:The values of second record of a multiple selection must be inserted into fields

Operating System: Ubuntu
Version: release
Comment 1 mishich 2013-12-25 16:18:44 UTC
Windows 7 LibreOffice the same bug.
Comment 2 mishich 2013-12-25 17:55:31 UTC
Windows 7 Apache OpenOffice 4.0.1 have the same bug.
Comment 3 retired 2013-12-29 12:21:21 UTC
Can you please provide a test document so this can be tested against and subsequently be confirmed. If your document contains sensitive data, please clear that or replace it with random information.

A step-by-step description of how to reproduce the issue is most helpful and will help to speed up the processing of this problem a lot.

Setting to NEEDINFO until more detail is provided.

After providing the requested info, please reset this bug to UNCONFIRMED. Thanks :)

Also OS > ALL since this seems to be happening on Windows too.
Comment 4 mishich 2013-12-29 14:31:02 UTC
Created attachment 91292 [details]
Database file to use in mergemail
Comment 5 mishich 2013-12-29 14:32:30 UTC
Created attachment 91293 [details]
Text doc i used to test mailmerge fail.
Comment 6 May 2014-01-14 13:59:11 UTC
Comment on attachment 91293 [details]
Text doc i used to test mailmerge fail.

By using the wizard, the "Insert Address Block" step, there is an error in selecting a database created with the help of the wizard. It is observed that the field called "table" wizard does not store the value, and therefore the accept button is not activated.

Al usar el wizard, en el paso "Insertar Bloque de direcciones", existe un error al seleccionar una base de datos creada con la ayuda de el wizard. Se observa que el campo llamado "tabla" del wizard no almacena valor, y por tanto el botón de aceptar no se activa.
Comment 7 Alex Thurgood 2014-10-19 16:29:45 UTC
Confirmed on LO 4322 OSX Yosemite
Comment 8 Alex Thurgood 2014-10-19 16:43:32 UTC
How to reproduce :

1) Download ODT and ODB files. Open both in LO.
2) In Writer document, remove all previously inserted fields.
3) Insert > Field > Other > Database
4) Insert Field1 into Writer document, press space key
5) Insdert Field2 into Writer document, press return key
6) Press F4 key, select any tuple greater than the first one, e.g. the second tuple
7) Click on the "Data to Fields" icon
8) See how only data from first record gets inserted

What should happen : selected tuple data should be inserted.
Comment 9 Alex Thurgood 2014-10-19 16:49:03 UTC
Reproduced also in 
Build ID: d807cba9ee60cb1404b54addf9cd3e54de89f331
Comment 10 Julien Nabet 2014-10-19 16:53:52 UTC
Jan-Marek/Lubos: seeing branches like "private/jmux/mailmerge-fixes", "private/llunak/mailmerge_01", I thought you might be interested in this one.
Comment 11 Alex Thurgood 2014-10-19 16:57:26 UTC
Note that if you drag and drop the field headers from the data source browser instead of using Insert > Field, the selected tuple is inserted correctly
Comment 12 Alex Thurgood 2014-10-19 17:00:02 UTC
I see the problem in 3672 as well
Comment 13 Lionel Elie Mamane 2014-10-24 21:57:06 UTC
When I follow Alex's instructions, the fields just end up empty (or just a space?), whether I take the first or any other record, and whether I use the drag-and-drop method or insert / field.

master (4.4.0.alpha) build of 26 sep 2014.
Comment 14 mishich 2014-12-19 03:45:15 UTC
(In reply to Alex Thurgood from comment #11)
> Note that if you drag and drop the field headers from the data source
> browser instead of using Insert > Field, the selected tuple is inserted
> correctly

It is inserted as text, not as field
Comment 15 mishich 2014-12-19 04:43:40 UTC
Screen capturing available by following link:
Comment 16 Alex Thurgood 2015-01-03 17:38:21 UTC Comment hidden (no-value)
Comment 17 Commit Notification 2016-01-15 15:41:27 UTC
Oliver Specht committed a patch related to this issue.
It has been pushed to "master":

tdf#73025: set absolute database index fixed

It will be available in 5.2.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 18 Xisco Faulí 2016-09-15 20:36:10 UTC
Is this bug fixed?
If so, could you please close it?
Comment 19 QA Administrators 2017-10-23 14:05:27 UTC Comment hidden (obsolete)
Comment 20 QA Administrators 2019-12-03 14:14:01 UTC Comment hidden (obsolete)
Comment 21 Timur 2019-12-09 17:27:53 UTC
I tried to test, but I couldn't confirm the report. 
It's either fixed or needs a new status.
Since nobody responded to QA ping, I'll close. 
But it would be useful to retest this.