Download it now!
Bug 31405 (Ribot2) - Connecting a SQL query to a form letter without using the mailing wizard
Summary: Connecting a SQL query to a form letter without using the mailing wizard
Status: VERIFIED FIXED
Alias: Ribot2
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: x86 (IA32) Windows (All)
: high normal
Assignee: Not Assigned
URL:
Whiteboard: target:3.7.0 target:3.6.3
Keywords: regression
Depends on:
Blocks:
 
Reported: 2010-11-05 01:01 UTC by ribotb
Modified: 2016-04-24 20:47 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample letter to test mailmerge (9.17 KB, application/vnd.oasis.opendocument.text)
2012-09-28 14:48 UTC, Nicolas R
Details
Sample letter (9.17 KB, application/vnd.oasis.opendocument.text)
2012-09-28 14:49 UTC, Nicolas R
Details
Database. Must registered as 'BaseNom' in LibO (3.76 KB, application/vnd.oasis.opendocument.database)
2012-09-28 14:50 UTC, Nicolas R
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ribotb 2010-11-05 01:01:34 UTC
When connecting a SQL query to a form letter in the mailing window (by the mailing button added in the standard toolbar or by Print > Print a form letter ? ) , this connection  no longer appears when the form letter is re-opened.
Therefore, in the data source explorer, the query must be re-connected.
Comment 1 ribotb 2010-11-05 01:13:02 UTC
This behavior is inconvenient for users who need to find - not without potential risks - good query before to start the mail merge.
Comment 2 ribotb 2010-11-05 01:14:02 UTC Comment hidden (obsolete)
Comment 3 ribotb 2010-11-05 01:14:44 UTC Comment hidden (obsolete)
Comment 4 Alex Thurgood 2010-11-18 10:00:23 UTC
I can confirm this on Mac OSX 10.6.5 with beta 3, and say that this makes mailmerge via this menu entry useless, because essentially it doesn't work at all on my machine.

I have used the "elements" test document and database provided in Bug 31585. If you try to print via Cmd-P, you get an error message stating that the data source can not be found and that you should check your settings.

If you then click on the "Check Connection Settings", the elements database shows up as being registered. There seems to be no way to get LibO to properly recognise that it is connected to a valid data source via the print out route.


Alex
Comment 5 Yifan Jiang 2010-11-29 22:41:44 UTC
Also happened on SLED 11 sp1 with LibO beta3 3.3. Not sure who's gonna taken this. We may want some Base expert to investigate this.
Comment 6 Nicolas R 2010-12-07 09:35:17 UTC
Please note that the behavior when a form letter is connected to a table in the database (and not connected to an SQL Query), it's almost perfect.

You can use directly Ctrl-P to print your mailmerge and the correct datasource is connected.

And better ! If you use data beamer (F4) to sort or filter your datasource easily, when you type Ctrl-P and accept to print a form letter, the "table" datasource preserves sorting and filtering.

Same behavior with "Sql queries" datasources will be really fine ( something like the old OpenOffice Bug/enhancement number 48059 )

It will be all great step forward for my company (many mailmerge with parameterized queries , and stick on Ooo 1.1.5 for theses peculiar tasks)
Comment 7 Alex Thurgood 2011-05-24 03:12:18 UTC
Setting confirmed status on whiteboard.

Alex
Comment 8 Björn Michaelsen 2011-12-23 13:22:45 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 9 Nicolas R 2012-09-24 13:07:22 UTC
According to the "FindTheExpert" wiki page. I've added <lionel@mamane.lu> to the CC-list.

Lionel, can you evaluate this bug , and possibly reassign or assign it ?

Thanks in advance
Comment 10 Lionel Elie Mamane 2012-09-28 10:15:04 UTC
(putting Alexander in CC since he reproduced this bug in the past)

(In reply to comment #9)
> According to the "FindTheExpert" wiki page. (...)

> Lionel, can you evaluate this bug , and possibly reassign or assign it ?

My "expertise" is rather strictly limited to database stuff. This seems to be about some way of using database data from within Writer, in a "mail merge" feature? I would need detailed reproduction instructions to take a look, since I know next to nothing about Writer.

The original report talks about "mailing window". How do I get to that window? What should I do in this window?

The original report talks about "mailing button added in the standard toolbar". When I right click on the toolbar, left click on "customise toolbar" and then the "add" button, I get many categories on the left. Where am I supposed to find the "mailing" button?

The original report talks about "Print > Print a form letter". In the File menu, there is a "Print" entry that opens a dialog, but nothing in this dialog says anything about a form letter.
Comment 11 Alex Thurgood 2012-09-28 14:29:32 UTC
(In reply to comment #10)

> 
> My "expertise" is rather strictly limited to database stuff. This seems to
> be about some way of using database data from within Writer, in a "mail
> merge" feature? I would need detailed reproduction instructions to take a
> look, since I know next to nothing about Writer.

I will have a look at it, but from memory, yes, attempting to do a mailmerge on a Writer template from a registered query and then closing, does not save the query binding to the template so that when you open the template the next time, you have to go through the mailmerge/print mailing assistant again.

I will try and draw up something you can use to reproduce.


Alex
Comment 12 Nicolas R 2012-09-28 14:48:34 UTC
Created attachment 67826 [details]
Sample letter to test mailmerge
Comment 13 Nicolas R 2012-09-28 14:49:38 UTC
Created attachment 67827 [details]
Sample letter
Comment 14 Nicolas R 2012-09-28 14:50:25 UTC
Created attachment 67828 [details]
Database. Must registered as 'BaseNom' in LibO
Comment 15 Nicolas R 2012-09-28 15:43:46 UTC
I've joined two attachments ( mistake in attachment type for the fist one) to reproduce the bug.

You have to register the database BaseNom.odb as 'BaseNom'.

This database is very simple and contains : 

- one table 'Table1' with id, firstname and gender code.
- one query with parameter : 'Query1'
- one query without parameter : 'Query2'.

Initially the FormLetter is linked to 'Table1'. You can change that with 'Edit -> Exchange Database'


> The original report talks about "mailing window". How do I get to that
> window? What should I do in this window?

Open 'FormLetter' and then 'File -> Print'. As the letter contains address database fields a dialog suggests to print a form letter. Accept that then you have the "mailing window".

When the formletter is linked to 'Table1', in this window the 'Table1 datasource' is selected.

When the form letter is linked to 'Query1' or 'Query2' ( using 'Edit -> Exchange Database') , nothing is selected.

> 
> The original report talks about "mailing button added in the standard
> toolbar".
Another way to have the same mailing window
> 
> The original report talks about "Print > Print a form letter". In the File
> menu, there is a "Print" entry that opens a dialog, but nothing in this
> dialog says anything about a form letter.

In fact, this is 'File -> Print', and you have a dialog only if the letter has database fields.

Oh, a good thing. If you filter / sort your datasource from the 'Data Source' window ( View -> DataSource or F4 key), when you 'File -> Print', the filter / sort is preserved in the 'Mailing Window' ( and better, if the letter is linked to a query, after reselected the query , filter and sort are also preserved).

So the real problem is : maintain link between letter and query in mailing window.


But perhaps this bug is for Cedric Bosdonnat ?

Many thanks to glance at this bug !
Comment 16 Lionel Elie Mamane 2012-09-30 06:12:49 UTC
The stuff happens in
sw/source/ui/dbui/dbmgr.cxx: SwNewDBMgr::ExecuteFormLetter

The problem is that this line:
  aDescriptor[daCommandType]  >>= nCmdType;

lets nCmdType set to 0 (that is, CommandType::TABLE), but it should set it to 1 (that is, CommandType::QUERY)

The weird thing is that this is supposed to come from the rProperties argument, but:

(gdb) print rProperties
$30 = uno::Sequence of length 3 = {{
    Name = "DataSourceName", 
    Handle = 0, 
    Value = uno::Any "BaseNom", 
    State = com::sun::star::beans::PropertyState_DIRECT_VALUE
  }, {
    Name = "Command", 
    Handle = 0, 
    Value = uno::Any "Query2", 
    State = com::sun::star::beans::PropertyState_DIRECT_VALUE
  }, {
    Name = "CommandType", 
    Handle = 0, 
    Value = uno::Any 1, 
    State = com::sun::star::beans::PropertyState_DIRECT_VALUE
  }}

The CommandType is is clearly "1", so maybe something is wrong in how
  ODataAccessDescriptor aDescriptor(rProperties);
handles stuff? Ah no:

(gdb) print aDescriptor[daCommandType]
$32 = uno::Any 1

So the problem is in the ">>="? That's weird. Ah... I found it... The Any contains a sal_Int32, and we are trying to stuff it into a sal_Int16... Changing nCmdType to a sal_Int32 should solve the problem.

Testing that fix...
Comment 17 Lionel Elie Mamane 2012-09-30 06:40:21 UTC
Yep, works!

Cédric & Michael, as Writer "FindTheExpert", I'll let you judge whether we want to backport

commit 3f84462b47f070b4921fdd5fdab8397ab1439fd6
Author: Lionel Elie Mamane <lionel@mamane.lu>
Date:   Sun Sep 30 08:35:03 2012 +0200

    Change-Id: I859c38c3589dc9e9ef5bdd882663aa3386a43237


to libreoffice-3-6; I've originally developed and tested the patch against my workdir of libreoffice-3-6.

Bug log contains the details.
Comment 18 Not Assigned 2012-09-30 06:41:24 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3f84462b47f070b4921fdd5fdab8397ab1439fd6

fdo#31405 CommandType is a LONG, so use a sal_Int32 to retrieve it



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 Nicolas R 2012-09-30 16:42:18 UTC
(In reply to comment #18)
> Lionel Elie Mamane committed a patch related to this issue.
> It has been pushed to "master":
> ...
> Affected users are encouraged to test the fix and report feedback.

Great !! It will be really useful in my company environnement, and I think for other people too.


I will test it as soon as possible and available in daily builds, so probably monday or tuesday.

Reading your comment, I suppose it's fixed in 3.7 branch ... except if Cédric or Michael backport the patch to the 3.6.x release.
Comment 20 Not Assigned 2012-10-01 10:08:42 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5b536e72f2a4e35275eb33317ec6b6e14845b75c&g=libreoffice-3-6

fdo#31405 CommandType is a LONG, so use a sal_Int32 to retrieve it


It will be available in LibreOffice 3.6.3.

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 21 Nicolas R 2012-10-06 15:16:23 UTC
Just tested with the 3.6.3 nightly build (dated 05/10/2010 "Version 3.6.3.0+ (Build ID: 1e73405)" ).

It's ok for me !

Many thanks
Comment 22 ribotb 2013-11-15 09:57:02 UTC
It's Ok for me (with LO 4.1).

Many thanks,
Bernard Ribot
Comment 23 Jean-Baptiste Faure 2016-04-24 20:47:36 UTC
Version set from description.

Best regards. JBF