Re: Database Options - Any other settings I should adjust?

"Steve" <steve@xxxxxxxxxx> wrote in
news:bJuLi.20$gu2.13@xxxxxxxxxxxx:


"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns99B9DEB6D9E2Bf99a49ed1d0c49c5bbb2@xxxxxxxxxxxxxxxxx
"'69 Camaro"
<ForwardZERO_SPAM.To.69Camaro@xxxxxxxxxxxxxxxxxxxxxx> wrote in
nf8Li.3$n92.1@trnddc06:">news:nf8Li.3$n92.1@trnddc06:

It's also usually
best to convert to an MDE and distribute the MDE database file,
not the MDB database file
f
This is another piece of common wisdom that I ignore. I've only
one case where I make sure the user has an MDE, and that's
because she has a tendency to type through the occasional
unhandled error message. Thus, I never hear about the error (she
didn't see it), and I end up being called in to revert the code
she typed into to its compilable state. So, she gets an MDE. All
my other users have MDBs, and it's Just Fine.


I always distribute the front end as an MDE. It adds a level of
security and control, that you don't get with an MDB. There is no
reason not too.

There are plenty of reasons not to:

1. inability to fix a bug over the phone without sending a new
update, or having the end user edit the MDB and generate a new MDE.
If you've got the MDB on the other end already, you haven't got too
much security.

2. supporting multiple versions of Access. In that case you have to
generate multiple MDEs, one for each version, and that's more
trouble than it's worth.

What kind of security do you think an MDE gets you?
.

Quantcast