How can I cripple an excel document after a certain date? I want it to become unusable after, say, 12/31/2009.
I was thinking about putting one of those Must Enable Macros things in there that hides all the sheets on close and leaves one tab that says you must enable macros. Then having an on open macro that unhides all those tabs, but also will close itself if after a certain date. This has a few drawbacks in that someone could just enter in the macro code (without macros enabled) and change the expiration date... or even just change their system time. Any thoughts about good ways to do it? Is my method pretty much as good as you can get? or are there better ways out there?
Thanks.
You might want to have a look at Microsoft's Information Rights Management (IRM) technology. IRM lets you control which users are permitted to read, edit, print etc the content of a document. It is also possible to specify an expiration date.
IRM requires you to either have an ActiveDirectory infrastructure with a domain controller or you may use the IRM service hosted by Microsoft.
For further details check out Controlling workbook access in Excel with Information Rights Management.
Dan, I am not sure of the purpose you are trying to lock the excel sheet. However if you write the macro then you can password protect the VBA code so that no changes are made to the code.
Having said so, there is still a possibility to have workarounds and access the excel file; no method can be foolproof.
Cheers...
Related
I designed an MS Access Database that reads the user's window's username and restricts access based on that, with some users having full access, some having partial/controlled access, and some getting kicked out on opening it. I work for a large organization (thousands of employees) but the DB is stored somewhere only some people can get to, so I don't need super security, I just want something to keep someone from stumbling into it and then breaking it.
However, since I am using VBA code for the security, if someone hasn't made the document "trusted," the VBA code doesn't run, and obviously it won't be trusted the first time they open it, so...my security does nothing. I'm trying to figure out a way to "fail closed," so people can't get in unless the Macro can run, and I was thinking I could password protect the DB and then have the macro enter the password, but I have no idea if that is possible, or how I would do it?
If someone has a better idea than a password lock of the DB, I'm happy to hear it. I'm nervous that the macro could break when there is no one around who would know the password...
Help??? Please?
Thanks
Edit, found this:
Excel VBA - Automatically Input Password Looks like the answer to my original question is no.
There is nothing in my DB that is really sensitive, I just don't want someone editing if they don't know what they are doing. Is there a way to set it to read only unless a password is entered? I guess I could set each table and form to read only and have the property change if opened by someone on the user list???
I'm happy to accept a "You are thinking about this wrong, here is a solution that doesn't do what you asked, but does what you want."
I need to be able to run my scripts and macros on my client's system without revealing my code. I understand that .vbe wouldn't help much. Is there any way around creating an .exe? But then again, macros would still be exposed. Obfuscate the code?
Would be moving to a python program soon, but until then...
Right click the VBAproject and click 'Project Properties' then select Protection tab and check 'lock project for viewing' and set a password. Now if anyone wants to view the vba files they need a password first.
END GAME: A user saved Workbook opens and mirrors code from a target file.
I am trying to create a simple VBA application that has an Excel front-end and an Access back-end. There will be multiple users who would have the option to save the front-end Excel piece anywhere they desire.
I would like to know the most efficient way to be able to update macros in all user instances when I need to push updates.
Essentially, I would like to mirror code from a "global" file on Workbook_open. In the past I did actually set code to open a separate workbook and run code (dim x as workbook, open, app.runmacro and etc.), But I think that is not really the most efficient way to do it.
Four possible solutions pop to mind for this (other than your option of having an intermediary workbook), there are likely others:
Treat the Workbook as purely an interface, and move the code to the
Access database and have it accept the Workbook as a parameter if
needed. The advantage would be the code could be maintained in one
place (Access), but it would have two main disadvantages. Each user
would need to have Access installed in order for it to instantiate
the application to call methods on, and it would lock in your
"interface" - that is, changes to how it calls Access macros would
still require Workbook updates.
Create a canonical Workbook and have the user Workbook version check
against the canonical Workbook when opened. If the version is
different, open the new one, move all of the data to it, delete the
old one, and save the new copy to the same filename as the old one.
The main disadvantage of this method would be ensuring that old code doesn't run might be difficult, as you would need
to take measures to prevent situations where the user could abort
the update process and still have a working copy of the old code.
Automate the VBE (see this answer for implementation details -
there are numerous resources on how to do this). Depending on how
you wanted to do this, you could either store the current modules as
files and import them, or store the code in the database itself and
query for it. The main disadvantages of this method are that the
VBE can be fickle about changing code that is actually running. I'm
not sure that I'd trust it to change it's own implementation. You
would also need to allow access to the VBE in each user's security
settings, which may pose a security threat.
Store the location of the Workbooks themselves in the database, then
push out updated copies with external code. The Workbook would
report it's filepath when opened, and if it wasn't already recorded
in the database, check to see if it was the most current version,
and then write a record for itself. This has the disadvantage of
only being able to inform the user that they don't have the current
version if they (for example) move the Workbook in Explorer and
don't open it until after your push.
Note that these are all "pull" type as opposed to "push" type solutions with the exception of the last one. Regardless of the method you use for version checking, any push solution is going to share the disadvantage of number 4 - there is no reliable way to make sure that a push catches all the invalidated versions.
first time asking something here, so I'll apologize beforehand in case I do anything I shouldn't do.
I'm working on a workbook and there are some information in it that shouldn't be available to everyone else, save a few users.
While doing some testing around I've found that it was possible to use another instance of Excel, i.e. another workbook, to access that information (in this case, using VBA).
What I want to know is: is it possible to block another instance of Excel or another workbook from accessing this workbook with the information I want to protect?
The point of this sheet in working on is to be used as a 'database' of sorts for performance feedback of other employees. They fill a form with their self evaluation and then their manager also fill it, evaluating them. All this is stored in a sheet, which is hidden (veryhidden, to be more specific). Using a simple login system, I was able to enable access to this sheet to only one user (one with admin privileges), but assuming someone knows the existence of that sheet, it would be perfectly possible for them to, for example, just copy everything from that sheet to a blank sheet in a new workbook.
Ultimately, what I'm trying to achieve is some kind of restriction in this workbook, allowing only it's own subs and functions to work on it
Thanks in advance
EDIT: Added some info. Hope that helped clarify my problem
The only way to achieve this is encryption. As far as I know Excel only supports one form of encryption, full workbook encryption. In that case there is a password to open the workbook, a user either has access to the full workbook or none at all.
Any other form of encryption in Excel, protected cells, passwords on macros, etc. can all be bypassed easily by a knowledgable user.
However, you could achieve this using either an external database server or implementing your own encryption scheme in the workbook.
There is some information here on howto access the Windows CryptoAPI from VBA.
I have a form that has a list box and several buttons that run sqk statements for the list box.
sub on_onClick()
' error checking
me.listbox.rowsource = "SELECT tblMain.First, tblMain.last FROM tblMain ORDER BY tblMain.Last;"
so this kinda thing is what I use for the list box. it works fine for me in the .mdb, and after i have converted the database, split it, made the .mde I go into the mde and it works fine for me still. This is placed on a shared drive
HOWEVER, anyone else that tries to use this, none of the buttons are having an effect. Can't tell if they are not working, or the VBA is not returning any results for them. It works for me, but it is not working for them. So...this is for my local LAN team, I think they all have full control permissions??? The button clicks that get them to that form are working fine also.
please help!
A couple of things come to mind:
It is not clear from your question whether the mde file itself is on a shared drive or whether the back-end database is on the shared drive and each user has a copy of the mde file on their PC. If the users are using the same mde file on the network share then I would strongly suggest not taking this approach. (It probably isn't the cause of the issue, but it will get you into trouble down the road.) Give each user a copy of the mde (front end) and have the application point to the back-end database on the network share.
Make sure that the mde has the ability to relink the tables to the back-end mdb file.If you search SO you'll probably find examples of how to do this in code.
I suspect you may be running into an issue where the mde file is not able to find the back-end tables. In this case you won't receive an error message in your VBA code when you're setting the listbox's rowsource and it will appear as though nothing is happening.
Do they have Macro security disabled? By default, MAcro security is enabled in Access and none of your VBA code will run. To disable: open Access, Tools -> Macro -> Security and set to low.
I think it is generally best to use self-certified projects or a secure location rather than change security levels.
Some information on macro security:
Self Certify projects
General information on security principals for Office code and macro security
Trusted location defaults for Office 2003
Macro security in Office 2003