Created attachment 84759 [details] File Utility Business accounting program containing the Worksheet PROSPETTO CODICI Problem description: in the Attached File Business accounting program for utility companies. Worksheet named : PROSPETTO CODICI Updating of a PivotTable Prospetto codici / SECTION CODICI AVERE (red numbers),already filled from PREVIOUS VERSIONS LibreOffice Cal 3.6, - Updating of a PivotTable from VERSIONS 4.1.0.4 THE TABLE "DELETE" FIELDS IN ITS STRUCTURE OF ORIGIN (THE FIELD 1) Steps to reproduce: 1. Change data in the Database origin 2. In the Pivot table, Mouse dx command, short menu, Refresh data The Pivot Table change (erase all outpout), for internal suppression the I field data. Current behavior:The Pivot Table change (erase all outpout), for internal suppression the I field data. Expected behavior:The pivot table to change the results by analyzing the database properly, according to the index of the fields (in this case I), as it was in earlier versions of LibreOffice in Allied: File Utility Business accounting program containing the Worksheet PROSPETTO CODICI Operating System: All Version: 4.1.0.4 release
Hi Michele, thanks for reporting. Reproducible. Win7x64Ult. Version: 4.1.1.0.0+ Build ID: c1f0f890f5065f88164add33707228f8c6d5755 Go to PROSPETTO CODICI.d3, right-click + refresh, PT result is lost. Editing no row fields there. Maybe some relation with my reported: https://bugs.freedesktop.org/show_bug.cgi?id=64441 Set up as Regression. Changed status to NEW.
I built 3.6, loaded the attached document and refreshed the table. And the table gets shrunk to just one data field result as in 4.0, 4.1, 4.2 and the current master builds do. So, as far as I'm concerned this is not a regression against 3.6 as originally reported. mariosv: do you happen to have a 3.5 build that you can test this with?
And so far as the shrinkage, that itself is expected given that the table only has one data field defined. Unless you have a row field defined, the pivot table output would only show one data field result, as Calc currently does. Or, is this bug about losing the row field definition during import? I need that clarified. Thanks!
The bug is present in: LibreOffice 3.3.4 LibreOffice 3.5.7.2 AOo 4.0.1 Sorry Kohei, my fault set up as regression. Usually I don't set up without verify, but I can't remember now.
So, Norbert also tried this using 3.3.0.4 on Mac. He loaded the document, then refreshed the problematic pivot table, and it still shrinks. I'd like to know exactly what version of what software was used to generate this document. Was it LibreOffice, OpenOffice.org, Apache OpenOffice, or ... ? Also, when you open the pivot table layout dialog on the buggy table, no row fields are defined. Do you expect to see a row field there, or is the row field box supposed to be empty? Sorry for a serious of questions, but I need a bit more help in order for us to work on resolving this.
mariosv: Thanks for the info. Especially it helps to know that AOO has the same issue.
One easy workaround is 1) Load the document. 2) Before refreshing the table, right-click, and select "Edit layout" (the top menu item). 3) Re-insert the "Cod. R/D" field into the Row Fields box. 4) Click OK. Then the pivot table will not shrink. Inspecting the content of the file, the field name is defined as "Cod. R/D" (there were 2 white spaces in between), rather than "Cod. R/D" with one white space in between. I'm sure that's what's throwing this off. No idea why the field name was saved with 2 white spaces instead of one, though.
I will remove the regression keyword for now.
I don't know the version used to save the file. As in bug Description: "... Updating of a PivotTable Prospetto codici / SECTION CODICI AVERE (red numbers),already filled from PREVIOUS VERSIONS LibreOffice Cal 3.6, - Updating of a PivotTable from VERSIONS 4.1.0.4 ..." seems it was 3.6. Don't seems possible save the file in these state. All versions 3.3.4/3.5.7/3.6.7/4.0.6/4.1.5/4.2.0/4.3.0, adding the field, saves and reopen fine.
The Kohei's comment #7, seems to solve the issue for every version. Saving again and reopening the issue is gone. Verified with: Win7x64Ultimate. LibreOffice 3.3.4 OOO330m19 (Build:401) tag libreoffice-3.3.4.1 Versión 3.6.7.2 (ID de compilación: e183d5b) Version: 4.1.6.0.0+ Build ID: 0b772a163b2536fc55aa3b4de925119e33af769 Version: 4.3.0.0.alpha0+ Build ID: b6a43bcbbf9e9a5655fd36fd4c8ef72d585f67b0 TinderBox: Win-x86@39, Branch:master, Time: 2014-03-30_06:16:21 Changed the status to resolved notourbug, because works fine saving with LibreOffice and we don't know which program/version was used to create the problematic file.