AutoExec Password

JReagan

Registered User.
Local time
Today, 12:13
Joined
Oct 13, 2009
Messages
32
Is there a way to have a database automatically fill in the password when its opened? I know that it sounds foolish to do this, but I want the database to be password protected so that individuals can't link or import objects out of my database. I still need to let users open it up, and I have it so that they can not get to the navigational pane, they can't use the shift bypass key, and the ribbon is blocked out so that they can't get to the access options this way.
I have forms in place to pull up on open so they can navigate and run reports they need, but I want to lock the objects (Queries and Tables) down as I have a co-worker who likes to copy my work and use as his own. Any ideas?

Thanks,
JB
 
well, if you've locked everything down, than that'll cover it I'm sure, but a database password is absolutely no good, and here's why: http://www.nirsoft.net/utils/accesspv.html

that works for mdb's only, but I'm sure the newer versions are out there.


Tried to view this at my work assignment.
The Corporate Internet Blocked my viewing claiming it is a "Hacking" category.

Guess it will have to wait until I get home
- When I get home, will be sure to use the "back door"
 
Tried to view this at my work assignment.
The Corporate Internet Blocked my viewing claiming it is a "Hacking" category.

Guess it will have to wait until I get home
- When I get home, will be sure to use the "back door"

well they've got it done pretty well then! I think what they might have done is checked a public db or something with known phishing history? I would assume it's some sort of security measure like that.

but yeah...it's quite a little program. only like 50K to the whole package! :cool:
 
I have a password set on it, but I don't give that out to the users of the database. I need the users to still be able to access this database to use the forms, but I just can't have them in the back end of it.
The version is 2007 and the file extensions are .accdb if that helps at all. Is there a way to lock down the queries or hide them so that they are out of view other than checking the "Hidden" box? Objects can still easily be viewed from a blank database and just checking the "Show Hidden Objects" box when you are doing an import or link.
I just want to keep this one guy out cause he seems to royaly screw things up and it helps me if I'm more proactive at just keeping him blocked from the backend.

JB
 
There is a way to protect Modules from being viewed in Access 2007, is there a way to do this with other objects as well?

JB
 
If your database is split then you can give them access to the front-end and the back-end can be password protected, manage the access to the back-end through your code/forms objects. You could either use database objects to open up the back-end on demand, or if you are using bound forms you can change the recordsource to a SQL statement using the IN clause pointing to the back-end, that way even if they somehow manage to get to a database window there are no linked tables for them to manipulate directly. Compile your accdb to an accde and distribute that version to your users.
 
I was lead to believe that splitting a database pretty much ment you could hide the tables and not queries. Am I incorrect about this?

JB
 
I was lead to believe that splitting a database pretty much ment you could hide the tables and not queries. Am I incorrect about this?

JB

Well whatever you put into the back-end could be effectively hidden from the front-end. Now if you are just using bound forms to tables/queries and calling macros to execute stored queries or using DoCmd.OpenQuery then you are limited in what objects you can put into the back-end without making some significant coding changes in the front-end.

It really comes down to effort vs. reward, it is very quick and easy to setup bound forms that rely on stored queries and tables, but there are security concerns as you can't really lock down those objects.

You could move to a split BE/FE, moving all your stored objects except for forms/reports/code modules to the BE. This is a bit more secure but requires more effort to setup initially especially if you have not done it before.
 
These are outside the scope of securing a database. However, if someone is in the planning stage these are some other considerations for security:

One option is to find out if your IT department has a Citrix server.
You will still want to split up the front end and back end.

Citrix allows the IT department to determine who can obtain a copy of the front-end on the server through a Citrix agent. The back-end is also controlled under network rights and un-obtainable to users (assuming Citrix is managed correctly).

A second option is to upgrade to Microsoft SQL Server.
The data and queries (views) can be stored on SQL Server and admin conducted with network login rights. Again, there is many ways to set up SQL Server security.
Basically, Access front end has tables linked to the back end that is SQL Server.
 
The following is all aircode and has not been tested.
Now here is something to think about. Lets say you have a table with a PK and a memo field and a text field. The text field will contain the name of the query. The memo field contains the SQL of the query.

Have a dummy set queries with no SQL in them.

No when you want to use or run a query you lookup the SQL in the table and use querydefs to reset the SQL of the query with the SQL from the memo field.

Then when you have finished with the query you wipe out the SQL from the query.

So when nosey parker gets in the front end and sees a list of queries and goes to design one all they will see is SELECT *

Alot of planning may be involved and some recording may be involved, but like it has been said before Does the effort match the reward?

The table remains in the back end and is not linked simply referenced.

Don't even know if it will work it is just something I thought of whilst reading the threads.
 

Users who are viewing this thread

Back
Top Bottom