Get Tables working on protected sheets (add rows, sort, filter, etc.)
I would like to be able to, under the right circumstances, have the ability to add/remove rows of a table which resides on a protected sheet.
Currently if you protect a sheet you can't insert/delete rows of a table. Even if you unprotect all cells and allow inserting/deleting of rows on sheet protection, it doesn't matter and is completely ignored.
What I am proposing would have to follow specific rules:
- Table cells would have to be unprotected
- Cells below table would have to be unprotected (truly optional † )
- Insert Rows would have to be specified in sheet protection
† The way table rows are inserted is different than a standard row insert. If there are blank rows below the table it will "consume" those rows, and not shift things down. If there is data below the table, once it consumes all rows between the two, it will start inserting. This mechanism would make the second item above optional depending on how you [Microsoft] would handle this internally. My preference would be to have the cells unlocked, and honor the protection status of the cell, and not overwrite, or "consume" if there is space available.
This has been BROKEN for some time. Since we can ALREADY do this with standard cells, it should ALSO work for tables. This request has come up multiple times, and has previously been rejected as "BY DESIGN", but I'm here to tell you - and I'm an expert - this is not by design, and is a bug which has been overlooked and should be fixed.
(2016-12-07 Dan B [MS]: updated title to capture the actual ask here, which is to make Tables work better on protected sheets; currently, since protected sheets were built "before" Tables, they don't work well with "Tables" or objects that adjust/expand within the grid as users interact with them)
Thanks for logging this great suggestion, Zack, and to others for voting it up. We’ll prioritize this according to the number of votes, so if there’s more interest, please make sure to register your vote!
Lead Program Manager
Marcos Rieper commented
You could add a Private Sub Worksheet_TableUpdate(ByVal Target As TableObject)
event macro and/or create a userform for the input to append to your table with an _afterupdate macro as part of the userform code. Setting protection on a sheet can include UserInterfaceOnly:=True when the Workbook is loaded for the sheets of choice, so the macro/userform can make the change without having to unprotect/unlock the sheet or table range.
Works brill for me on a distributed workbook. Specifically, since macros have no permission to change tables such as listrow.add, the userform must append the data to the table. The table will then automatically expand to include the new line.
With UserInterfaceOnly:=True set there's very little not allowed on a protected sheet, changing tables sizes (exception wishlisted) and pivottable cache refreshes are just the few I've come across which need programmatic temporary unlocking, do whatever, and relock for routine user activities.
Found a partial workaround to 'append' data but determining the size of the table and subsequently using range/cells/offset to get an entry right below. The table and any column formula will create the new record with the auto-expand function, from which point on Listobjects() can be used to further add data to that and any other records. The UserInterfaceOnly:=True in the Thisworkbook module's Workbook_Open macro sets the prerequisite for macros to be allowed the manipulation on protected sheets with locked cells.
Facing such issue..
Israr Ahmad commented
Sayam Rafique commented
Microsoft Excel my goal is to make the whole sheet uneditable and editable both at the same time.
For instance, I'm using Table1 and with every new entry, one row adds up in the table, but the whole table is prone to risk of being mistakenly or deliberately removed/edited. I want to make a new entry (which will add a new row, aa usual) but the whole should remain protected/locked (unchangeable). Have i conveyed my point?
Just ran into this brick wall. Microsoft pitches using tables and structured references and then gives no way to lock the formulas down in an expandable table except data validation (slows things down so much it takes a few seconds to add a row) or VBA. If Microsoft wants large organizations to work their way up to power BI, it'd be a lot easier if I could demonstrate with tools mgt already has confidence in (e.g. tables, spreadsheets, etc.)
Robert Robson commented
This is 7th most voted open idea on the list and the comment from the admin didn't change for almost 2 years.
The discussion on using VBA and Data Validation shows just how important it is for Microsoft to do this properly rather than forcing people into messy workarounds.
@Pavlo Burchenko: Yes, the error checking rules apply to the local copy of Excel where they are set. However, you can disable error checking on workbook open and then restore the user's previous settings on workbook close with a little VBA: https://www.ozgrid.com/forum/index.php?thread/29089-disable-error-checking-via-vba/&postID=1035971#post1035971 .
Still looking for a way to disable just "Data entered in a table is invalid" with VBA. It doesn't appear to be one of the properties offered in the ErrorCheckingOptions object: https://docs.microsoft.com/en-us/office/vba/api/excel.errorcheckingoptions . The closest I could find, "Application.ErrorCheckingOptions.InconsistentTableFormula = False" disables "Incosistent calculated column formula in tables" instead.
Pavlo Burchenko commented
@Miles Wolbe: Thanks for the links!!! Regarding Data Validation workaround, hinding error notifications will only work for your workstation. Other users will see the error notifications it once opened on their workstations. This is because such settings are local and independent from the file.
@DMT: Thanks for the heads up. You're right; while the data validation hack works to protect cells from users typing into them, it does not prevent users from pasting into them. However, an error is displayed with an option to "Restore to Calculated Column Formula", even if the "Data entered in a table is invalid" error checking rule was disabled as previously described.
@Miles Wolbe - but the data validation is not working, since users can just copy-paste on top of validation and over-write all your rules.
In the meantime, some VBA workarounds:
Autoexpand Excel Tables on Protected Sheets https://www.excel-first.com/autoexpand-excel-tables-on-protected-sheets/
Protect sheet but keep table expandable https://www.excelforum.com/excel-general/1115066-protect-sheet-but-keep-table-expandable.html#post5140971
and a neat Data Validation trick to protect cells without having to use Protect Sheet:
Protect Cells in Excel Using Data Validation https://www.accountingweb.com/technology/excel/protect-cells-in-excel-using-data-validation
Since your formulas protected via Data Validation will likely show green flag errors, hide them via File > Options > Formulas > Error checking rules > uncheck "Data entered in a table is invalid".
Any information on whether there is any intention to address this issue?
Any solution as yet ?
Any update after 3 years?
Aside from visual basic, are there any good methods for us to insert or delete rows in a protected sheet without giving up passwords to the users?
Oliver Wilcock commented
Thanks, Eckhard, for expanding the scope of what could be much better about structured tables. I've also been frustrated by data validation along with the show-stopper protected sheet issue. I didn't know the workaround you described.
I've also cursed Microsoft when trying to retrieve data through ODBC/Jet. The table is not stored as a range and Jet doesn't find it.
I've found business users very reluctant to embrace tables and I think the largest barrier is the behaviours when adding, removing and especially moving columns (cut and paste). I haven't fully wrapped my head around what it does. I know it messes up the column widths. The workaround I use is to insert a new column in the sheet and then to cut and paste the table "Entire Table Column" into the new location and then delete the unwanted sheet column. Unnecessary hassle.