Created attachment 104322 [details]
this is a screen shot showing what will be saved and what will be lost
This bug probably is a functionality that has adverse implications not considered. In query builder, can make column not visible by checking box on grid. See screen shot. Bug: when the box is not checked and the query is saved, the column is deleted on close. This leads to unexpected data loss. The typical use case is the query just has a table column, so no real loss, however the query also can contain formulas; if user wants to delete the formula, can decide to do that deliberately. Making column not visible and closing query builder leads to nonobvious deletion and data loss.
1. Create query.
2. Add fields.
3. Make one or more fields not visible by unchecking box.
4. Save and close.
5. On reopen, columns will be gone, including any formulas.
Expected functionality: on reopen, formulas will be available to be made visible again without re-drafting.
Consider adding a warning when columns are made not visible and the query plan will cause deletion of that information/column on close.
P.S. test document will just have missing columns.
P.P.S.: I believe this bug may be connected to application instability, failure to close normally, but cannot reliably reproduce application instability.
You could hide columns, which shouldn't be shown.
Only columns would be saved, which should be visible or which have any function for the query, for example only sorting data or someone else.
I couldn't confirm the field is lost in the query-design, if it has a function, which would attach other fields. Have tested it with grouping by a non visible column and sum of the other column. Works as expected, shows also the non visible column in the GUI when I reopen the query for editing.
My System: OpenSUSE 12.3 64bit rpm Linux, tested with LO 188.8.131.52
Yes, problem of unexpected loss of data would be solved by treating clicked "visible" box as request to "hide" column, rather than remove it from the query plan.
And yes, bug does not impact query execution, only causes unexpected deletion of field contents being used to edit query.
Win 7 64-bit Version: 184.108.40.206.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08
(In reply to Beluga from comment #3)
> Can't repro.
1. Create a query.
2. Set one of the fields not visible.
3. Save the query.
4. Close the query.
5. Reopen the query for editing.
If you can't reproduce the non visible field has been gone it seems there had something been change, special in Windows.
Here it has been gone, hasn't been saved together with the query. Have tested it with LO 220.127.116.11.alpha2+ OpenSUSE12.3 64bit Linux.
For me it is a ask for an enhancement. It is a special problem of Base: Every formatting in a query isn't been saved together with the *.odb-file. Only the SQL-code would be saved. And this code doesn't have any hint for non visible columns.
There should be a way to save such an information. There are some more formatting-informations, which aren't saved: Width of a column, hiding of a column, other formatting of a column ... All this is saved for tables, not for queries.
(In reply to robert from comment #4)
> (In reply to Beluga from comment #3)
> 1. Create a query.
> 2. Set one of the fields not visible.
> 3. Save the query.
> 4. Close the query.
> 5. Reopen the query for editing.
> If you can't reproduce the non visible field has been gone it seems there
> had something been change, special in Windows.
Yep, that was what I did and the field was in the editor with its visible checkbox unticked. Only change was it had moved to the right (switched places with one visible column).
Reproducible with LO 4.3.5, win7 .
I can confirm with Version: 18.104.22.168.alpha0+
Build ID: 7f476fea47f06a7f8cc961dd4f6595a524346fa5
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-12-27_23:36:28
Setting as enhancement, see comment 4.
Adding self to CC if not already on