October 7, 2009 at 5:39 pm
How do I assign a password so that others can not open mdb files?
Now, we assume we are given a password for the user.
When the database is detached, then I copy the mdb file to another computer
and I open with a different database engine, so I can open database file without using a password.
Any suggestion? or my explanation was wrong?
Regards,
Eko Indriyawan
October 7, 2009 at 6:39 pm
You want to properly institute file system security. If you do that, only an administrator can override you. And if the person is an administrator, they can get access to the data in those files as soon as you attach them to the SQL Server. So if someone isn't trustworthy with the files, they had better not have administrative rights on the servers in question where the .mdb files reside.
K. Brian Kelley
@kbriankelley
October 7, 2009 at 7:00 pm
I'm as a Developer. I afraid when sell my application, my customer can open all the stored procedure and endpoint that I have been created. if they use for their own needs I am not worried, but if there are programmers who want to steal, I became worried.
Please advise...
King regards,
Eko Indriyawan
October 7, 2009 at 7:28 pm
The problem is you can't stop them. If you don't encrypt your stored procedures and the like, they can simply view the defintions of them. Even if you do, there are techniques, even in SQL Server 2005/2008, to decrypt them. So if your code is in T-SQL, it's trivial to get the code out. If it's in .NET, there's .NET Reflector. Your best bet is proper licensing agreements and a legal option.
K. Brian Kelley
@kbriankelley
October 8, 2009 at 12:44 pm
If it hasn't been mentioned, try posting in this newsgroup...
Based on your original post, it sounds like you want to prevent a user from directly access SQLServer objects that are exposed via the .mdb file.
Assuming that that's correct...
1) I've worked with Access for a good long time and while I've never had to deal with Access security, everything that I've read seems to indicate that its somewhat lacking.
2) That being said, my approach has always been to view it from the standpoint that I'm simply putting into place roadblocks to preventing someone else from doing something untoward. Access security certainly being one of the roadblocks. Other roadblocks include...
-If you're using Access strictly as a front end to SQLServer, converting the MDB file to a MDE. This strips out all of the code from the file leaving the database objects. And limits the functions that the user has access to.
-Dynamically linking the tables when the file is first opened so that if the startup procedure is bypassed, which is possible, the user doesn't see any linked tables and then detaching them when the file is closed, although detaching them is not guaranteed if Access ends abnormally.
-Naming the tables linked to SQLserver with the USys prefix. Access recognizes anything named as USys as a system object and automatically hides it by default. Although this can be overridden.
-Implement custom toolbars/ribbons that strips out everything except the bare minimum of commands.
-Hiding the database window. (http://www.mvps.org/access/general/gen0031.htm)
-You do not need to have a file extension of .mdb for Access to open it. You could rename it with any extension.
-Ensure that only authorized users have the file. If you are using Access as a front end, the front end should be on the user's machine to begin with as opposed to sitting out on a file server in a shared directory.
...again the idea is to put up roadblocks.
October 8, 2009 at 12:54 pm
eko indriyawan (10/7/2009)
I'm as a Developer. I afraid when sell my application, my customer can open all the stored procedure and endpoint that I have been created. if they use for their own needs I am not worried, but if there are programmers who want to steal, I became worried.Please advise...
King regards,
Eko Indriyawan
I missed this post when I replied. Nearly all of the roadblocks that I mentioned still apply - especially converting the MDB to a MDE. You can go one step further. Some developers will use custom properties to capture device specific information to ensure that the mdb cannot be run on another machine without a license key.
The code here should enable you to retrieve a MAC address so that approach is possible.
http://vbnet.mvps.org/index.html?code/network/macaddress.htm
Post to the newsgroup that I mentioned as there have been similar questions posed with responses that include detailed instructions and links. I know that one technique also uses a custom registry key.
When you post, be certain to state that your concern is preventing a user from moving a MDB/MDE file from one machine to another.
October 8, 2009 at 1:09 pm
Thank you very much for your advise.
King Regards,
Eko Indriyawan
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply