https://bugs.documentfoundation.org/show_bug.cgi?id=162617
--- Comment #3 from Robert Lacroix <mux...@hotmail.com> --- (In reply to Regina Henschel from comment #2) > Use a Database Range for your data and base the Pivot Table on this range. > When you want to add data to that range, go to the last row of the range and > click on its row number. From context menu use "Insert rows below". I know > it sounds silly to "insert a row below" if the cells are already empty. But > this action extends the range. Now you can write your data into the empty > cells. Refresh of the Pivot Table considers the newly entered data this way. > > You can test that this works, when you use "select database range" before > and after. This sounds plausible and even makes sense from the point of view of working with a database. But inserting rows below the table sounds "hackish". If I recall some 30 years ago (or I might be dreaming), MS Access has a permanent empty row at the bottom of a table, with a row number like "*" which is not part of the table data until something is typed into it (and then it receives a real row number, and a new empty "*"-numbered row appears after). LO-Calc does not have the luxury of infinitely extensible tables, but neither does Access. Could we do something like Access - have a special-purpose empty last row in a database range which is part of the range only for the purpose of adding data and extending the database range (and thus also pivot table ranges bound to it), but otherwise exclude the special row from database operations and pivot table operations? And if the so-extended database range runs into non-empty cells the database table would be "full" and deny new data entry until rows are inserted between the database range and the content below, or the content below cleared away. There's a precedent for special row treatment for pivot table source data - the first row of the source range contains field names. So it's not unreasonable to have special treament for the (empty) last row of a pivot table range if it's a database range. The proposed enhancement as originally stated does away with the need for a database range, by sensitizing pivot tables to nonempty cells adjacent to the bottom of the source data range. Of course this might break existing spreadsheets, and there must be a popup confirmation about extending the pivot table source data range (which could be disabled by the user). I'm not denying that using a database range with pivot tables could add value, especially with automatic range extension as discussed above. I even imagine that binding a pivot table to a source range could automatically make the source range into a database range. Would this paradigm shift break anything? If so, then would it be reasonable instead to have a chechbox in the Pivot Table Layout dialog to make the pivot table source range into a database range if it isn't already? The checkbox would show the current state of the range as a database, so if it's already a database range it would appear checked when the dialog is opened. Just an idea to explore. -- You are receiving this mail because: You are the assignee for the bug.
