Without using an .mdw file, is there a way to STOP anyone from importing objects from an .mdb? I have a vba program that stops them from using the shift key to bypass the startup form. It would be helpful if I could also "shut off" the ability to import objects from my mdb.
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 derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
import objects from one mdb to another 4
- Thread starter OhioSteve
- Start date
-
1
- #2
- Thread starter
- #3
I want to force the user to interact with the database using my gui interface. I found a function that disables shift-bypass, which is cool. But I want to stop them from creating another mdb and using import/export.
Your suggestion may not be ideal for me. I would need to tell the user the password. Then he could use it during an import/export.
Your suggestion may not be ideal for me. I would need to tell the user the password. Then he could use it during an import/export.
- Thread starter
- #5
I experimented with your suggestion. I must admit that I did not know about that feature. It does provide good protection to the code module. However, it only protects the code module not the tables.
Frankly, to protect my code in modules I just compile from an .mdb to an .mde. Is there some reason to password-protect modules instead of compiling them?
Frankly, to protect my code in modules I just compile from an .mdb to an .mde. Is there some reason to password-protect modules instead of compiling them?
- Thread starter
- #7
-
1
- #8
- Thread starter
- #10
This thread is getting quite interesting.
scottian, your suggestion is REALLY cool. Perhaps we could make it even better. I have a function I found online. I have used it for years to permanently disable shift-bypass. However, I suspect that you could use it to disable other properties. Could I use it to suppress the "view hidden objects property"?
__________________
Public Function SetProperties(strPropName As String, varPropType As Variant, varPropValue As Variant) As Integer
On Error GoTo Err_SetProperties
Dim db As DAO.Database, prp As DAO.Property
Set db = CurrentDb
db.Properties(strPropName) = varPropValue
SetProperties = True
Set db = Nothing
Exit_SetProperties:
Exit Function
Err_SetProperties:
If Err = 3270 Then 'Property not found
Set prp = db.CreateProperty(strPropName, varPropType, varPropValue)
db.Properties.Append prp
Resume Next
Else
SetProperties = False
MsgBox "SetProperties", Err.Number, Err.Description
Resume Exit_SetProperties
End If
End Function
scottian, your suggestion is REALLY cool. Perhaps we could make it even better. I have a function I found online. I have used it for years to permanently disable shift-bypass. However, I suspect that you could use it to disable other properties. Could I use it to suppress the "view hidden objects property"?
__________________
Public Function SetProperties(strPropName As String, varPropType As Variant, varPropValue As Variant) As Integer
On Error GoTo Err_SetProperties
Dim db As DAO.Database, prp As DAO.Property
Set db = CurrentDb
db.Properties(strPropName) = varPropValue
SetProperties = True
Set db = Nothing
Exit_SetProperties:
Exit Function
Err_SetProperties:
If Err = 3270 Then 'Property not found
Set prp = db.CreateProperty(strPropName, varPropType, varPropValue)
db.Properties.Append prp
Resume Next
Else
SetProperties = False
MsgBox "SetProperties", Err.Number, Err.Description
Resume Exit_SetProperties
End If
End Function
-
1
- #11
Before you go too far with this, change the visible property of a table and then open a new database and tick Show Hidden under Options on the Tools menu, you will find that you can now see the hidden table when you choose import. Show Hidden applies to the application, not the particular database, unless there has been a change since the 2000 version.
-
1
- #14
- Thread starter
- #15
Let's say we have a.mdb. A curious user creates b.mdb and tries to import from a.mdb into b.mdb. At that instant, does any sort of event happen in a.mdb? Something must tell a.mdb to put up the password message box...because if you password-protect an mdb, then it challenges users that try to import from it.
jkl0, your suggestion might work if my concern was a hacker not connected to our company. However, I am actually concerned about legitimate users that want to "improve" or "learn about" my application. If Access tries to use a linked table in a password-protected mdb, it asks for the password. Under your scenario, I would need to tell the users the password so that they could use the product. And when they tried to import from another .mdb, they would know the password.
jkl0, your suggestion might work if my concern was a hacker not connected to our company. However, I am actually concerned about legitimate users that want to "improve" or "learn about" my application. If Access tries to use a linked table in a password-protected mdb, it asks for the password. Under your scenario, I would need to tell the users the password so that they could use the product. And when they tried to import from another .mdb, they would know the password.
- Thread starter
- #16
OOH...I just thought of a fantastic idea. Does the show hidden objects property map to a windows registry key? I am the administrator for these laptops. I could just set that registry key to false. And most amatuers are terrified to even type "regedit".
- Thread starter
- #18
PHV~
You are the Yoda of Access developers. I installed the linked table manager. Then I linked x.mdb to a password-protected mdb. After providing the pw and establishing the link, I closed x.mdb. Finally, I opened x.mdb again and browsed the linked table. I was NOT prompted for a pw!!
So I think we have a consensus on what a developer can do to mitigate risk (without using an .mdw):
DURING DEVELOPMENT
1. Split the product into a front end (a.mdb) and a back end (b.mdb). Password-protect b.mdb.
2. Set the hidden attribute to true on every object in a.mdb and b.mdb.
3. In a.mdb, create a startup form and create a toolbar and a menu bar for it. Suppress the database window, the default toolbars, and the default menus.
4. Run a function that disables shift-bypass....so the user cannot suppress the startup form in a.mdb.
5. Store sensitive values like connection strings as global variables in a module in a.mdb. Don't store them in a table. Compile a.mdb into a.mde.
DURING INSTALLATION
1. Put a.mde and b.mdb on the laptop.
2. sure that the "show hidden" attribute is set to false for this copy of Access.
3. Install the linked table manager for this copy of Access.
You are the Yoda of Access developers. I installed the linked table manager. Then I linked x.mdb to a password-protected mdb. After providing the pw and establishing the link, I closed x.mdb. Finally, I opened x.mdb again and browsed the linked table. I was NOT prompted for a pw!!
So I think we have a consensus on what a developer can do to mitigate risk (without using an .mdw):
DURING DEVELOPMENT
1. Split the product into a front end (a.mdb) and a back end (b.mdb). Password-protect b.mdb.
2. Set the hidden attribute to true on every object in a.mdb and b.mdb.
3. In a.mdb, create a startup form and create a toolbar and a menu bar for it. Suppress the database window, the default toolbars, and the default menus.
4. Run a function that disables shift-bypass....so the user cannot suppress the startup form in a.mdb.
5. Store sensitive values like connection strings as global variables in a module in a.mdb. Don't store them in a table. Compile a.mdb into a.mde.
DURING INSTALLATION
1. Put a.mde and b.mdb on the laptop.
2. sure that the "show hidden" attribute is set to false for this copy of Access.
3. Install the linked table manager for this copy of Access.
- Thread starter
- #19
- Thread starter
- #20
Actually, PHV, I experienced a problem implementing your suggestion.
Just to jog everyone's memory, let me recap the scenario. I have a.mde and b.mdb. b.mdb is password-protected and it contains the tables. The linked table manager in a.mde handles the connections to the tables in b.mdb. a.mde contains the gui interface for the application. Obviously a.mde is compiled.
A user creates x.mdb and tries to import objects into it. What can he get:
He tries to get table data from b.mdb~ he fails because it prompts him for a password
He tries to get vba code from b.mdb~ he fails because there is no vba content in b.mdb, just tables
He tries to get vba code from a.mbe~ he fails because that code is compiled
He tries to get table data from a.mde~ he succeeds because the linked table manager in a.mde provides the password to the backend.
Previously, we did not think through that last possibility.
However, Scottian's suggestion is still valid...hiding the objects does *mitigate* your risk.
It is too bad that .mdw files are so awful.
Just to jog everyone's memory, let me recap the scenario. I have a.mde and b.mdb. b.mdb is password-protected and it contains the tables. The linked table manager in a.mde handles the connections to the tables in b.mdb. a.mde contains the gui interface for the application. Obviously a.mde is compiled.
A user creates x.mdb and tries to import objects into it. What can he get:
He tries to get table data from b.mdb~ he fails because it prompts him for a password
He tries to get vba code from b.mdb~ he fails because there is no vba content in b.mdb, just tables
He tries to get vba code from a.mbe~ he fails because that code is compiled
He tries to get table data from a.mde~ he succeeds because the linked table manager in a.mde provides the password to the backend.
Previously, we did not think through that last possibility.
However, Scottian's suggestion is still valid...hiding the objects does *mitigate* your risk.
It is too bad that .mdw files are so awful.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question