Hello,

Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document.
(Please note that the attachment will be public, remove any sensitive information before attaching it.)
How can I eliminate confidential data from a sample document?
https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F
Thank you

Created attachment 121504 [details]
a database and created reports

Thank you for fast response.
Here are some files that may give a better view of the problem: a very small database with one table and simple report generator plus three report files (one created as "ODF text document", second as "Microsoft Word 2007-2013" and the last one as "Microsoft Word 97-2003") - all of them with the same content but different extension given by the LO itself.

Thanks,
Tom

This would be an error - LibreOffice doesn't currently support creation of reports as Microsoft XML, so the switch to default to such formats should perhaps include a warning that it will not be applicable to database reports.

That said, I'm not best placed to decide whether we should offer that possibility anyway. Personally, I don't see as a particular advantage, the whole point of the report writer is to produce ODF compliant documents from a linked database, but I can see the argument of wanting to be able to produce docx reports if the UI appears, via an application default setting, to offer that possibility. I also don't know how well our reports with various components (e.g. charts) currently export to docx (via the Save as menu), I would assume not very well, so this would open up a whole can of worms on that side. 

Confirming with regard to the application switch that doesn't offer what is written on the box, but opening up for debate as to whether it should.

Just to be clear, if one does "file / save as" from the generated report, and saves *there* as "Microsoft Word 2007-2013 XML", then it is correctly saved as .docx, right?

I don't understand this "Tools/Options: Load/Save -> General / Always save as"... "Clearly" only Writer obeys that... I can't imagine Calc or Impress following that setting. But nothing in the setting says it is for Writer only. IMHO, that's a UI problem.

(In reply to Lionel Elie Mamane from comment #4)

> Just to be clear, if one does "file / save as" from the generated report,
> and saves *there* as "Microsoft Word 2007-2013 XML", then it is correctly
> saved as .docx, right?

Yes, I tried this yesterday and could open a normal report (i.e. containing tabular formatted report data) in Word 15.17.1 on OSX.


> 
> I don't understand this "Tools/Options: Load/Save -> General / Always save
> as"... "Clearly" only Writer obeys that... I can't imagine Calc or Impress
> following that setting. But nothing in the setting says it is for Writer
> only. IMHO, that's a UI problem.


Some large business deployments, e.g. corporations and administrations use this option as a default to "trick" users into thinking that they're working with a MS-Word clone, or because they have a policy of always saving to docx, but as far as I understood, yes, this only applies to word processing documents.

And personally I agree, it is more of a UI problem, but perhaps there is more to it than I know about. Maybe one of the devs more aware of what this option does can shed light on it.

It looks like I found quite nice inconsistency :)

And yes, I got confused by the "Load/Save" section because there are separate sections like "LibreOffice Writer" or "LibreOffice Base" available only in Options menu opened from corresponding program. So the first guess is that those parameters are common for the whole suite (and they are - to some extent).

The only reason for changing that "Always save as" field, is dealing with huge report (>10 fields per record, one record per A5 page, about 2000 records) that freezes Writer for minutes (or even hours on some machines) when loading the document. The only option discovered so far is to save it as .doc(x) as MS Word deals with such big table with no delay. So I still consider reporting at least an enhancement against Writer's performance for this issue.

I understand your doubts about possible complaints related to compatibility, but I also have hard task to explain the final user of my database why she has to drink at least 3 coffees or teas before the generated report may be eventually printed.

(In reply to Sparrowbe from comment #6)
> dealing with
> huge report (>10 fields per record, one record per A5 page, about 2000
> records) that freezes Writer for minutes (or even hours on some machines)
> when loading the document.

Wow!  It had never occurred to me that one would use LibreOffice to
process a file of that size.  Clearly, we do not handle this well.  I
wonder if *should* handle it.

Let me confess that I am an old-fashioned (and old) guy, accustomed to
creating reports by a loop: { read one record, print one record }.
This new-fangled PC with its concept of loading a whole file at once
leaves me befuddled <grin />.

So I ask ... 
(*) Looking for solutions within whole-file-at-once paradigm: Can we
    make LO work with a document this size?  Is it a reasonable amount
    of work?  Is there much demand?
(*) Is there anything in a report definition that would make it hard
    to process it in one or more sequential passes over the input,
    producing for example .pdf output?  Sparrowbe, would this meet
    your needs?

Terrence, thank you for your comment on the topic.

My use case is to have kind of logbook of events, with possibility to add new entries either manually (with a nice Form) or by copy-paste from external spreadsheet. Then I have to print the subset of records in a form of a booklet. There is no need to edit the report before printing, so pdf suits my needs as well. However I miss a possibility to export only a slice of a table instead of the whole content (but let's leave this aside).

Regarding the Writer's performance, I created new Bug 96720 as I've investigated the problem more and found some other inconsistency in the content of the Base-generated .odt that may possibly lead to already mentioned freezes - the same file saved directly from the Writer is handled flawlessly.

Kind Regards,
Tom