Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Is it possible to prevent access tables from being imported.... 1
- Thread starter jlitondo
- Start date
-
1
- #2
Hi!
Right click on your tables in the secure data base and choose properties. At the bottom of the properties sheet there is a check box to make the tables hidden. As long as they are hidden and outside database will not be able to see them to link or import. Of course a person with access to the database will be able to show hidden or to unhide them, but then that person would not need to import them anywhere since they already have access.
hth
Jeff Bridgham
bridgham@purdue.edu
Right click on your tables in the secure data base and choose properties. At the bottom of the properties sheet there is a check box to make the tables hidden. As long as they are hidden and outside database will not be able to see them to link or import. Of course a person with access to the database will be able to show hidden or to unhide them, but then that person would not need to import them anywhere since they already have access.
hth
Jeff Bridgham
bridgham@purdue.edu
Jeff (or any expert): Does hiding truly restrict scope, or just simply "hide" it. IOW, if the perpetrator knew the table name, could they then still get it?
Man, that's pretty scary, or pathetic, or I don't know what. That is amazing if you really can simply import anything you want from secure DBs ??!!!
Moreover, assuming hiding does the trick: how many times will designers remember to do that; and then, how much developer's pain results from obvious offshoots of using "hiding" on something you're developing with (e.g. having to unhide to do something, then rehide). Yuck - kind of like having to update a read only file. And this is all assuming that hiding indeed solves the safety issue!
Wow, this is astounding stuff, are you sure?!
Man, that's pretty scary, or pathetic, or I don't know what. That is amazing if you really can simply import anything you want from secure DBs ??!!!
Moreover, assuming hiding does the trick: how many times will designers remember to do that; and then, how much developer's pain results from obvious offshoots of using "hiding" on something you're developing with (e.g. having to unhide to do something, then rehide). Yuck - kind of like having to update a read only file. And this is all assuming that hiding indeed solves the safety issue!
Wow, this is astounding stuff, are you sure?!
- Thread starter
- #4
larry, I feel your concern. It surprised me when I tested my database to see if any objects can be imported into another database and everything except for the tables cannot be. And the database is very secure except for this.Hiding the tables that you don't want imported does seem to work even though it is a cumbersome way of going about it. In my case, I was very concerned about just a few tables being imported. jlitondo@gatecitysteel.com
Hi,
I tried this out myself but was prompted for PW BEFORE the table/s would link or import into a new DB.
Using access 97 here.
I would be VERY concerned if it was as simple as importing tables from a "secure" db into mine.
petrosky Remember- It's nice to be important,
but it's important to be nice
I tried this out myself but was prompted for PW BEFORE the table/s would link or import into a new DB.
Using access 97 here.
I would be VERY concerned if it was as simple as importing tables from a "secure" db into mine.
petrosky Remember- It's nice to be important,
but it's important to be nice
Yep...I totally agree with petrosky...if you have a database password, you're tables cannot be imported unless someone wants to crack the password (which we all know the code exists out there to do it). If you have no database password set, you're pretty much out of luck; doesn't matter if you blank out all startup options, disable the bypasskey, use autoexec macros, etc etc...
Now, out of curiosity, does anyone know if it's possible to write a code module that checks for authorization each time a table is accessed? There's a way to use a database without tables, and that's by using binary access...but seriously now, how many people want to use a forward-only recordset for every database they create?
Now, out of curiosity, does anyone know if it's possible to write a code module that checks for authorization each time a table is accessed? There's a way to use a database without tables, and that's by using binary access...but seriously now, how many people want to use a forward-only recordset for every database they create?
Guest_imported
New member
- Jan 1, 1970
- 0
In ACCESS, it is a very simple to bypass the startup, even if it is disabled. Once that has been accomplished, you can simply use make table queries to export the tables. That is, for those tables that are secured. Also, you can write a module for those folks that won't leave your tables or applications alone. Try the deleteobject action. That will get their attention if they copy or move your tables, WACK! no more tables. Should prompt a telephone call to you to fix their boo boo.....
Terry
Terry
- Thread starter
- #8
I disagree with forgotmypassword, what you do in access is call a function to disable the bypass(shift) key in your startup form's "Open" event.That disables the shift key being held down to reveal the standard menu bar which you need to disable and use custom ones that would limit users to very specific functions. jlitondo@gatecitysteel.com
jlitondo:
I have to chime in with forgotmypassword.
The easy way to work around your method is to override the shift bypass from outside Access. Then by holding the shift key your code to re-enable it does not run. Just in case you're wondering, such a utility exists, it's available for download on my website (you probably didn't want to hear that).
"The Key, The Whole Key, and Nothing But The Key, So Help Me Codd!"
I have to chime in with forgotmypassword.
The easy way to work around your method is to override the shift bypass from outside Access. Then by holding the shift key your code to re-enable it does not run. Just in case you're wondering, such a utility exists, it's available for download on my website (you probably didn't want to hear that).
"The Key, The Whole Key, and Nothing But The Key, So Help Me Codd!"
- Thread starter
- #10
couple of things.The solution that I provided forgotmypassword with was one set for Access 2k and earlier versions. I'm running Access 2k2 and determined(beleive) that if you set the startup options right, the shift by-pass function is not required because access 2k2 handles this internally and holding down the shift key doesn't work. Can you override that externally?
Also, simply setting a database password cannot work for a multiuser database that is to be used by several people with different levels of access to the database as you need to set up a workgroup inorder to achieve this. jlitondo@gatecitysteel.com
Also, simply setting a database password cannot work for a multiuser database that is to be used by several people with different levels of access to the database as you need to set up a workgroup inorder to achieve this. jlitondo@gatecitysteel.com
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question