Protect forms and code without MDE

Hi,  I have an application that cannot be an mde because it is necessary to be able to customize report layouts and save the changes, however I still want to be able to protect my forms and code.

I am going to use the method shown at: http://www.experts-exchange.com/Databases/MS_Access/Q_20401357.html to disable the shift key on startup, so users can't access the database window, but someone who knows Access can simply create a new database and import all of my forms and code, bypassing that security.

Does anyone know of a way to secure my forms and still retain customizability on the reports?  I cannot use user permissions, because it needs to be easily distributable in many environments.

Thanks in advance for your comments.

Terran
earthman100Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

jadedataMS Access Systems CreatorCommented:
Hey earthman100!

  You can try setting the Hidden attribute on those items so they can't immediately be seen.  But,. nothing short of making a tightly secured MDE file is going to get the job done.

regards
Jack
0
rthomsenCommented:
What about setting a database password.  No one will be able to import your objects without knowing the password.  It is still a step down from user level security.

Tools - Security - Set Database Password...
0
earthman100Author Commented:
rthomsen - That would require that they know the password to run the application, which is no good

I just tried the Security Wizard, and I think it seems to be getting me the results I want, but I need to know how to transfer this over to the end user.  Will they have to set up special permissions on their machine?  Where is the workgroup file located, and can it be tampered with if I distribute it with the application?

Thanks!
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

TextReportCommented:
When securing the database you need to provide them the MDW file and a way to ensure it is used. The best way to ensure the correct MDW file is used is to create a shortcut

"c:\program files\microsoft office\office\msaccess.exe" "c:\MyDB.mdb" /WRKGRP "c:\mysystem.mdw" /USER MyUserName

The /USER is optional and you can also specify the opassword by anyone can find that if you do.

BTW I would say Secure fully your app as an MDE and provide them a seperate MDB where they can write their own queries and reports. Then when you do an upgrade you do not have to worry about their objects.

Cheers, Andrew
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
earthman100Author Commented:
Andrew,

Actually they won't be creating their own queries or reports; I am using a function to allow them to create a custom paper size for the pre-made reports, hence the need for the reports to be alterable.

I'm just wondering, since I haven't used workgroup files before, is there a way someone could create another workgroup file to get them into the app?  Would they have to know my admin password for it to be successful?

Regarding your sidenote:

Is there a way to open reports in a separate mdb using code from the first?  

If so, that would solve all my problems right there.  If it has to be in a separate interface, it wouldn't really work, as the reports need to be accessed in context, because they key on variables in the program.

Thanks for your opinions so far!  I feel like I'm on the right track...

0
TextReportCommented:
If you load the second database as a library (reference to it) you can call a function in the Library that opens forms or reports from the library, the only problem is that the library might need to be an MDE

If the library has to be an MDE file then put all your app in the MDE and tlet them have the MDB as a front end.

Another option is to use CREATEOBJECT or SHELL to run another instance of access that then opens the report.

On the security for them to create an identical MDW file with the samer security they have to use the same PID's and SID's and Name including case so very unlikely unless you leave that info lying around.

Cheers, Andrew
0
earthman100Author Commented:
Thanks for your info Andrew.  That gives me enough to go on, with several options.  I think I will opt for the workgroup id, as it is easiest and still gives me the flexibility I need.

Cheers!

Terran
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.