After layering on all this security, is there a reason to also go with
.mde?
Actually I would've just created a mde, check to few boxes to hide the MS
access interface, and you are much done.
As a general rule we use security to prevent certain users from accessing
certain forms (ie: the sales group might see some sales reports, that you
don't want the data entry people to see for example).
In almost all cases it's still better to always distribute a mde to your
users. there are several significant advantages from a developer point of
view:
-- by compiling to a mde, you ensure there are no compiler (syntax) errors
in your code. It is quite amazing how many times the question in this
newsgroup comes up that a person can not create a mde. When we ask are there
errors in the code when you cmopilte, 9 out of 10 times...that is the
problem. This simply means that people have code in production use with
syntax errors. simply adopting the habit of using a mde eliminates this
possibility of sending out code with compile errors.
-- There are some instances and some types of code that can cause your
application to become un compiled, and this can significantly affect load
times of your application. It therefore can also be a source of bloat for
your front end. So, there are performance issues, and load time issues that
can be significantly affected here. I suppose in a way it also means that
you can't have any code that modifies the designs of forms or reports
directly, and in a sense, that's also a good thing about mde.
-- another really significant advantage is that any untrapped error in a mdb
will reset all the values of all variables, including global variables. All
of my applications have a good number of global vars like recordsets etc.
that remain open during the operation of the application. I'm not a super
duper developer, and therefore not all of my code routines have error
handling code in them. The simple solution in this case is to distribute a
mde to users. The beauty of a mde is that unhandled errors anywhere in the
application never destroys the local or even global variables. With a mde
some little error will not cause values of variables to be lost, and in most
cases your application will simply soldier on as if nothing's happened. The
end result of this is that mde's are MUCH more robust and solid in general
use and operation (it in a sense turns your application into a solid running
Swiss clock). I never have to worry about some little error damaging and
causing problems to any of my global or local variables losing values. With
mdb, one tiny error, and ALL OF your variables are blown out...
-- workgroup security is only secure for very casual users, there's a
significant number of password crackers available on the Internet that can
be purchased and downloaded that will bypass workgroup security. In other
words the security is great to keep people out of seeing certain reports,
seeing certain reports etc. However, users who want to view code etc. are
somewhat more advanced, and a determined person will break this security.
Once again, in this regards using a mde is far more robust and far more
secure in terms of protecting your forms and code from being viewed.
As I said before security is not really made to protect your code and forms
from modification. While security can accomplish this, it more used to GIVE
different accesses to different parts of the application. I would not as a
general rule suggest using security to keep person to people from modifying
and viewing your forms code, it's not what security is designed for...
-- mde's are smaller, and do run a faster then a mdb. For the most part, the
run issue is not large, but there are some forms etc. that you will notice
run a bit more snappy as a mde. And, they are smaller to distribute
All of my applications are distributed as a mde...including those I secured
using workgroup security. I as a general rule use a mde to protect code and
forms from my users, and security is used to control WHICH users can see/use
what report. Using an mde, and that of workgroup security really are
considerably different issues.
