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."
Related
first time poster here
I am looking for a specific VBA solution and I just can't seem to google my way to the exact code I need - thus, I come here
I have an excel sheet with an existing connection to a sharepoint database. It calls this connection "toolbase"
I need code so that when this sheet loads up it fills its second sheet with a dump from that connection as if I pressed the Existing Connection > Connect > import table button. Its the only known connection to the sheet.
That's it - and for the love of my feeble VBA skills then I can't find the code for this. My boss just wants a list that refreshes itself every time the file loads. I know where to put the code - I just don't what to write.
Can someone help me out?
EDIT:
The closest I could find to what I think I need is something akin to this: https://support.microsoft.com/en-us/kb/306125
but that seems to be talking about extracting records - I need the whole table
Once the data connection has been made, just have ActiveWorkbook.RefreshAll assigned when the workbook opens.
You do need to show some research effort or attempted coding in future questions though (even if it's wrong) as this is not a free coding service (i let you off this time as the answer is a one liner ^^).
Here's the short version... let me know if any additional information can help.
I have an Excel document on SharePoint. I have two users who both are in the same security group and both have contribute access to the document.
On one user, workbooks.cancheckout("http://address/document") returns true as long as nobody else has it checked out. As designed.
With another user, workbooks.cancheckout("http://address/document") returns false. All the time.
The user CAN check the document out directly from SharePoint, so this is NOT a permissions issue. I believe it has something to do with the way Excel is trying to talk to SharePoint.
What causes "cancheckout" to return false, and does anyone have any suggestions on what is causing or how to fix this error?
The working user is using Office 2010. The broken one is 2013. However, several other users, all on 2013, are not having the error. OS is Windows 7 for all users.
I has similar issue. I asked user to manually access share point portal document from their desktop and then use excel VBA program. It works. if you change password then you have to manually go to share point and access that document so your credentials are stored somewhere in cache. It is wired but this is they way I resolved problem faced by one of my user.
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.
Just a little background: I am using Access 2010 to create forms and VBA code in an Access 2003 format database. For some reason, Access 2007 format databases always corrupt on me when I make changes and save them with a particular group of objects, but that's for another discussion.
When writing VBA code in this Access 2003 database, any time my code breaks (via breakpoint or an unhandled error) and I make a correction, Access tells me that it can't save back to the database because another user has it open. However, I am the only user working on the database; this is a local copy of the database and it's sitting on my desktop.
The LDB file can't be deleted because Access is using it. When I first load the database, I see my machine name and "Admin" when opening the LDB in a text or hex editor. After a break, I see that plus a duplicate entry, but this time around "admin" has a lower-case "A."
Closing the database and reopening it fixes the problem but makes it needlessly cumbersome to debug my code. Anyone else encounter this issue and/or have a fix for it?
It might be helpful to know what your code is doing when this happens. Certainly that's not normal behavior. For instance, are you opening another database with New Access.Application? Are you using ADO or DAO to access records in the database with a connection string?
There are no external connections to the database at all.
It may not matter if there are external connections to the database if you are using a connection string to connect to the open database; not sure but that may be seen as an external connection... you may want to use CurrentDB for DAO, or CurrentProject.Connection as your ActiveConnection for any ADO queries.
I am assuming that this problem persists through reboots; but for the sake of argument, try closing out Access and going to the task manager to make sure you have no other instances of MSAccess.exe running. You might even try closing all Office products and/or making sure that Access is the only Office product running. I have seen some weird conflicts between Microsoft Communicator and Outlook; so it's not entirely out of the question for Access to have issues with another MS product.
You may also want to check the size of the database to make sure it's not exceeded 2GB. That causes the infamous "Invalid parameter" error; perhaps it might be causing this as well.
With no other details about how your program works, we may only be able to offer generic advice like this.
I have discovered a way to cause the problem discussed above (and thereby to correct it). Turns out if you create a database object and set it to the current database, you get this problem.
That is,
dim cdb as database
set cdb = currentdb
From this point on, you're cooked.
Instead, figure a way around this by possibly using currentdb directly or not using it at all.
This worked for me.
In your VBA Try checking that all your open Connections to the database are closed. Until the connection is open the LDB fill will be there.
Same symptom of not being able to save form or code mods after application had started. I found a workaround today! In the startup of my first form of the app, I had issued a "DAO.DBEngine.SetOption dbMaxLocksPerFile, 20000". Commenting this statement removed the problem. I did no further testing, but FYI, the DBEngine call was before any reference or attempt to use CurrentDB(). Also the current default on my Access 16 install is 9,500.
I thought I might answer here, since I stumbled upon this question while having a similar issue. Essentially, it boiled down to this: I could either edit forms, VBA, etc. or edit information in the local database (which I'm using as a cache) with currentDB. I also have a backend database, but the locking was clearly on the frontend database.
The solution ended up being weird, but stupidly simple. When the frontend starts up, I have it immediately create a connection to the backend using OpenRecordset (and similarly to you, that backend was still on my own computer for testing purposes). I tried temporarily disabling that code, and suddenly it wasn't an issue anymore. And it turns out, once I call currentDB, I can then call OpenRecordset to open the connection to the backend, and suddenly it isn't a problem anymore.
Tl;Dr: if you're calling OpenRecordset somewhere in your code to connect to a backend, be sure to call something like set db = currentDB beforehand, then everything works. (That is, probably until I publish this answer and Access then decides it doesn't want to anymore).
Why this fixed it is beyond me, someone with more knowledge can maybe answer that.
The solution:
options > current database > click enable -track name auto correct info
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...