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.
This behavior is inconvenient for users who need to find - not without potential risks - good query before to start the mail merge.
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
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.
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)
Setting confirmed status on whiteboard. Alex
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.
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
(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.
(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
Created attachment 67826 [details] Sample letter to test mailmerge
Created attachment 67827 [details] Sample letter
Created attachment 67828 [details] Database. Must registered as 'BaseNom' in LibO
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 !
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...
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.
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.
(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.
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.
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
It's Ok for me (with LO 4.1). Many thanks, Bernard Ribot
Version set from description. Best regards. JBF