I have a excel file that I need to give to a client. It currently comprises of one worksheet but could easily have many more. On the sheet there is a graph and a selection of slicers.
The problem I have is that if I hand this over to the client, they'll see the underlying code and possibly not need our services going forward.
How do I protect the sheet/file and only allow them to view data and operate the slices without seeing any of the background workings?
They must not be able to save a copy, access the SQL code or save changes.
Thanks,
JJ
You can bolt down excel with the protection options so that people can't edit objects and can only select non-locked items. You can also password protect vba and force read-only open of the spreadsheet.
http://office.microsoft.com/en-gb/excel-help/password-protect-worksheet-or-workbook-elements-HP010078580.aspx
There are lots of protection options available but the best thing you can do is reference a report/webpage with the data on instead of doing a direct db connection. This will alleviate a lot of security risks whilst also blackboxing your database.
IMHO
Only lock your spreadsheet down enough to prevent silly mistakes - combined with your data being a blackbox, they will get a usable spreadsheet and be much happier with you than if they felt you were aggresively trying to withold stuff from them. They may run off with your spreadsheet but the extension of trust to them will help discourage the behaviour and at the end of the day, if someone wants to really harvest your IP, they will do so no matter how many controls you have in place.
you also can try to protect VBAProject at the VBA window, something like this:
and put a password
this way the user can manipulate the worksheet without seeing your code, additional to this, block your worksheet like #StephLocke saids.
Your Workbooks can always be vulnerable, but you can lessen the risk to corrupt your code.
PS. My Excel is Spanish but the options are at the same place.
It is possible to protect the worksheets and still allow to interact with the slicers (and only the slicers).
Set each slicer's properties to not "Locked" by right clicking the slicer and selecting "Size and Properties..." and unsetting the "Locked" property.
Protect all other worksheet elements including cells and Pivot Charts in a similar fashion (set their "Locked" property).
Finally, protect the worksheet via “Review” -> “Protect Sheet” and select "Use AutoFilter" as the only action in the selection "allow for all users of this worksheet to".
You might also confer to this answer.
Related
This is a bit of a niche question, as generally it would be preferable to protect the sheet, but I would argue in some cases you simply need to protect the contents of the cell to avoid accidental edits and deletions without limiting editability of the sheet as a whole through Protect Sheet, such as creating new filters.
My Issue:
I have a need to export Revit schedules through a script to an excel spreadsheet for editing, then to import back into Revit. This is because editing elements, especially rooms, can be taxing with the size of our projects and lack of intuitive and quick ways of sorting and replacing contents within Revit schedules. I created a macro that will save the Excel file's fullpath (UNC path for shared network drives), among other things, to a config file to essentially "link" the schedule to that Excel file. If an excel file is not found in the config file, then I create one with through OpenFileDialog() with CheckFileExists = false, and so arises the issue.
If I create a new Excel file and use the Microsoft.Office.Interop.Excel method sheet.Protect("password") when saving the file, the user who export to the newly created file needs to know where to look through the macro in order to unlock the sheet to do some setup that a protected sheet disallows. This would also allow them to alter any protected data, purposefully or otherwise, and compromise the validity of the data. What's worse, if/when I have time to make this into a more developed addin to Revit rather than a macro, the used password would be hidden, disallowing even more trustworthy, advanced users from setting up the sheet. If I allow the user to set the password on creation of the new Excel file, then they can just unlock it whenever they want.
The Need:
The data exported with this script contains an ElementId for the Revit element in addition to what is contained within the Revit schedule, which is needed to tie the Excel data back to a Revit element with 100% accuracy (this is the only unique property of an element that does not change while the element exists). If this is altered in a way that creates a duplicate value in the Excel file, the validity of the import is ruined, and a rollback necessitated (which increases in severity the longer this error goes unnoticed).
Simply hiding the ElmentId column does nothing to prevent user nosiness from unhiding it, and Protect Sheet disallows a small set of needed alterations to the sheet when a new Excel file is created.
So, I need to "protect" against accidental alterations the ElementId column, but still allow for the alteration of that small set of features disallowed by Protect Sheet.
Again, I realize this is pretty niche need and not generally a desired limitation for protecting data. I also realize this does nothing to protect against deletion of the row as with Protect Sheet. That said, my goal is to prevent the alteration of an ElementId value in Excel from being edited into another valid ElementId value, nothing more. As such, deletion of a row would simply mean that the Revit element associated with that specific ElementId would not receive any form of update upon importing the data, as the cell is either null which is skipped or contains an invalid ElementId which can't be associated to an existing element, thus protecting the validity of said element data.
There are two solutions to this. The first was through my own experimentation. The second is a line of thought spawned thanks Solar Mike reminding me of an all too useful feature that I forgot about due to lack of use (generally do not have a need for it): Very Hidden Sheets. The avenue he seemed to be suggesting may not work exactly as he intended as, ideally, this Revit macro and Excel file combo should be usable by anyone in my company, but there is a method to make it work for anyone. Below are the two methods to resolve my issue, and hopefully anyone else in a similar bind that is, for some reason, unable to use Protect Sheet to do this job.
Solution 1: Data Validation
By setting Allow: Custom and Formula: "", I can trigger the Error Alert feature with Style set to "Stop" that will disallow any alterations.
Even better, if I want to disallow the deletion of cell data, unchecking the "Ignore blank" box causes an Error Alert upon hitting the Delete key on the cell as well.
Using this in conjunction with hiding the column obfuscates the process for editing these cells through sheer volume of steps to enable editing, discouraging users from bothering to mess with cell contents.
Pros:
Can utilize Input Message to warn users of the danger of altering cell contents
Can use Error Alert to outright block data entry or deletion of cell contents
Requires additional steps before people can alter values, using effort as a deterrent
Cons:
Does not protect against the following (read further for detailed
descriptions):
Deletion of rows (offset by using this macro on the workbook in
the Visual Basic editor)
Copy and paste another cell(s) over read-only cell(s) (working on a
macro to eliminate this issue)
Alteration of cells through code or macro
Requires macros to mitigate some of the above limitations, which can be
disabled and put data at risk of outlined issues.
Requires additional column (which can and likely should be hidden) in
your data, which becomes obvious to those who look at column letters.
Does not prevent people from turning off data validation, should someone
deem the effort worth it
Deletion of row:
This does not matter as much for me with this solution, as I am reading data from excel row by row, using the ElementId cell to find the Revit element. If an Excel row was deleted, the associated Revit element simply misses get data with that import, and is then re-added into the Excel file from the schdule upon the next export run, as long as the element still exists in Revit. But if row data needs to be maintained to avoid data corruption in your situation, you can use the linked macro to disable it.
Alteration by code:
At least external code; I have not tested this against a VBA macro from within Excel, but I assume the same to be true. I reason this is due to the fact that Data Validation is activated by a user interacting with the cell on an interface level, but when writing to the cell using the Microsoft.Office.Interop.Excel library in C# you are bypassing the interface and interacting directly with the cell data, thus not triggering Data Validation. I am not concerned about security or validation issues arising from this as few in our AEC firm know how to code, and the ones that do have no reason to interact with these files and/or lack the permission to access the folder (seperation of disciplines). While imperfect for most cases, this is the best solution I can come up with for our current needs.
Solution 2: Very Hidden Sheet
This method utilizes two features of Excel:
Very hidden sheet visibility setting
Macros
Specifically, the macro I am referring to is the link from Solution 1's Con section, Prevent Row/Column Removal.
The solution is to have your script write to two different sheets, one for your overall data, and the second for your unique identifiers. The writing of these should be coded in such a way that you would write to a line in each sheet before moving to the next one to ensure the identifier and data are placed on the same row and to reduce errors when editing the code in the future.
When saving the newly generated and format- and filter-less Excel file, set the identifier sheet's visibility to xlSheetVeryHidden, or 2. This setting should be exposed through the Interop.Excel interface as a worksheet property. This way, only advanced users who can use macros can unhide the sheet, and that's if they even know to look for it.
Pros:
Ensures unique identifier is accessible only to those explicitly told of its existence, and even then only to those with the ability or given the tools to access it
By utilizing the Row Deletion Prevention macro, identifier will always be paired with correct data, as long as code writes the data to Excel correctly
Is more secure than Data Validation by way of eliminating copy/paste as a risk
Cons:
Requires file to be saved as .xlsm, or Macro Enabled Workbook, which depending on your company's security settings may send a red flag to those who are unfamiliar with why the file is set this way
If macros are disabled via security settings, validity of data cannot be guaranteed as the row deletion prevention would be disabled
Final Thoughts
While I prefer Solution 2 and the usability it would provide, I can't in good conscience use it. Our firm's OOTB Excel install disables macros by default, and several people consider them non-essential to their tasks in the file and just ignore the warning at the top of the file all together. The risk of data becoming compromised purely because someone doesn't want to enable macros is too great.
I'd also like to add: If you are not in exactly the same situation as me, I do NOT readily recommend either solution. Protect Sheet is the strongest way to protect cell data, and does not disallow the use of existing Sort/Filter features. I am only using these as my go-to solutions due to the experience and/or knowledge level of those in the office who could potentially use my macro (and hopefully future addin), and recognize that neither route is a perfect defense.
If anyone has any other suggestions, I'd appreciate hearing them and I'll definitely update this answer if/when I have a better working version of either solution going.
I could not find an answer to this, neither on Stack or on the wild web. I have a sheet where I need users to be able to use Text to Columns, however, I also need to protect the sheet. Everything works fine if Excel automatically does this (from Text to Column "short-term memory"), but I cannot access the option when protection is enabled.
It is not that any text is spilling onto locked cells, it's just that the option is greyed out after protecting the sheet. I would appreciate a non-VBA answer as I do not want to use macros on a shared file (the server is extremely slow and even normal excels take ages to save). However, if absolutely necessary, can you ninjas please tell me how I can set it up so that this problem is solved with the least possible performance hit?
P.S.: I am pretty new to VBA (practically uninitiated, I prefer R for everything). Also, the shared server is basically a network folder, so it is not likely that it will cause any issues other than being super-sloth.
If you protect a sheet, then only unlocked cells can be edited, that is, users can change the cell manually.
That is the core and purpose of sheet protection.
In a protected sheet you will not be able to perform a text to columns manually.
Whether or not the file lives on a server is totally unrelated to using VBA for a solution.
The real question is: What are you trying to achieve? Your question is about running Text to Columns on a protected sheet, but if you step back from that particular approach, there may be other ways to achieve what you really need to do.
I have a workbook I have created with lots of different formula's. My question is, how can I stop the end user from stealing the formula's? I have had a look at: Protecting Code in an Excel Workbook?
This is generally for VBA. Is there a way to stop users doing this, or is it just worksheet protect and cross your fingers?
You probably should be more specific on what formulas are you trying to protect: Excel Worksheet formulas of the VBA code?
In general, you can create a custom VBA Add-in (i.e. .xla file) and protect it with password as per Excel documentation. In case your major concerns relate to worksheet function, then you can include them in said VBA add-in using for example, Range.Formula (re: https://msdn.microsoft.com/en-us/vba/excel-vba/articles/range-formula-property-excel ) or Range.FormulaArray properties.
Hope this may help.
There is no way to fully protect formulas in Excel. For every password protection type, there is a way to break that protection. The only thing you could do if you really wanted to prevent end-users from getting the formulas is to hard-code the entire sheet before sending it to them. Of course, if the workbook relies on user input and using formulas to output an answer, that won't work.
Do you need the formulas protected for some sort of IP reason, or just to prevent people from messing them up?
When I change my excel workbook to shared mode and try to copy and paste rows that have drop down lists (Data validation List), the drop down disappears.
It works fine as long as the workbook is not shared. Any solutions?
Set the Workbook to unshared, copypasta your data and then share the workbook again.
Shared workbooks are useful, regardless of their (many) limitations. In a shared workbook, you cannot:
Create an Excel table
Insert or delete blocks of cells
Delete worksheets
Merge cells or split merged cells
Add or change conditional formats
Add or change data validation
Create or change charts or PivotChart reports
Insert or change pictures or other objects
Insert or change hyperlinks
Use drawing tools
Assign, change, or remove passwords
Protect or unprotect worksheets or the workbook
Create, change, or view scenarios
Group or outline data
Insert automatic subtotals
Create data tables
Create or change PivotTable reports
Write, record, change, view, or assign macros
Change or delete array formulas
Use a data form to add new data
Work with XML data
Before you unshare the workbook, ensure no-one else is using it by clicking Share Workbook in the Changes group on the Review tab.
Select the name of the user who you want to disconnect, and then click Remove User.
Shared workbooks have severe limitations. Some functionality is disabled in shared workbooks. Other stuff just slowly starts to fall apart.
Consensus amongst Excel experts is that shared workbooks should be avoided, because it's not a quesiton of IF but WHEN they will become corrupt. Shared workbooks are impossible to troubleshoot.
Yes, Excel offers the feature, but it was never designed for simultaneous multi-user write access to a data set. If you need that functionality, you'd be better off with a database like Access or SQL.
Don't shoot the messenger.
I had similar issue and searched to find that there is no scope to add drop-down to the shared workbook. I got my work done by simply removing share option in the workbook, applied desired changes and shared the workbook again. :)
I have employees that use a macro/external data enabled Excel file. One of the worksheets in this file contains proprietary data, that is populated from an external data source ODBC connection. This proprietary worksheet is always hidden from the user, because it just serves as a Vlookup-function data-source
I want to prevent my employees from accidentally emailing this Excel file, because I don’t want the hidden worksheet data to be available to non-employees
Please advise if there is anything I can do prevent the email recipient from being able to view the data that is in the hidden worksheet, if the app is accidentally emailed to them.
Are any of the following ideas feasible?:
Password protecting the hidden worksheet, yet, not preventing the Vlookup function from the other worksheet from functioning?
Imbedding something into the app that resembles a virus, to cause all email servers to block the attachment.
Creating a macro that deletes the data from the hidden worksheet when the app is closed
Imbedding large images into the app to make it too large to email, but yet won’t affect the performance.
Please advise, thank you very much in advance, Nathaniel
In regards to number 3, there is a setting like this in the Connection Properties. It's "Remove Data from the external data range before saving the workbook." I'm not looking at XL 2003, but it's nested under the "Refresh Data When Opening the File" option. As others have said, this isn't foolproof, but it might help meet your requirements.
I don't think you can fundamentally prevent your workbook to be sent around. Password-protecting the sheet would be of little help, as it is fairly easy to bypass. The safest approach to protect your proprietary data from prying eyes would be to not have it in the worksheet itself, retrieve it dynamically by prompting the user for some credentials, and never save it in a worksheet.
You can hide the sheet from the developer tab of excel. To do this, follow the steps below
Open the excel
Press Alt + F11
Here you can see the list of sheets on your excel file
Select the sheet that you want to hide
When you select the sheet you can see the properties of the particular sheet below
Set the visibility property to ‘2 – xlSheetVeryHidden’
Now right click on the sheet and select VBAProject – Project Properties
Navigate to the Protection tab and check ‘Lock project for viewing’
Set a password
Sheets hidden in this way cannot be un hidden unless one has access to the VBA Project (but this is now password protected). The sheet can be seen only if you know the password.