Access database setup for data entry only

[leamunt]

Is it possible to set a database up for data entry only? I want to set up a
front end that allows the user to access the created forms and reports but
not have access to the design wizards. I need a GUI interface that allows the
user to enter data and print reports, nothing else.

 

[bcap]

Before distributing your front-end, convert it into an mde file (or an
accde).

 

[Bob Larson]

Just so you know what is and what isn't possible with an MDE/ACCDE -

Form, Report, Macro and Module changes cannot occur with an MDE/ACCDE.
However, a user can still (if they have the full version of Access)
modify/add/delete tables and queries (which can honk things up too).

--

Thanks,

Bob Larson
Access MVP
Administrator, Access World Forums
Utter Access VIP

Free Access Tutorials and Resources: http://www.btabdevelopment.com

 

[bcap]

Unless, of course, some clever-dick user simply renames it back to accdb.

 

[Larry Linson]

Unless, of course, some clever-dick user simply
renames it back to accdb.

It's possible to break security, and there are some third-party "things"
that claim to turn an MDE back into an MDB, but I suggest you might want to
"compile" a database to ACCDE, just rename it to ACCDE, and see just how
much additional privilege you get. (My prediction is "none" -- be sure to
let us know what happens.)

Larry Linson
Microsoft Office Access MVP

 

[bcap]

It's possible to break security, and there are some third-party "things"
that claim to turn an MDE back into an MDB, but I suggest you might want
to "compile" a database to ACCDE, just rename it to ACCDE, and see just
how much additional privilege you get. (My prediction is "none" -- be
sure to let us know what happens.)

Larry Linson
Microsoft Office Access MVP

Hi Larry,

AFAIK, the "things" which claim to turn an MDE back into an MDB claim to
recover the design of your forms and reports, but they don't claim to
recover your code.

Not sure what you are getting at with your suggestion of renaming an ACCDE
file to ACCDE, I think you might have made a typo. I was replying to the
suggestion that the OP renames his ACCDB file to ACCDR. This will indeed
cause the file to open in "runtime mode", but it's hardly secure because all
that's needed to get it to open in "full mode" is to rename in back to
ACCDB!

 

[bcap]

But (i) in any properly-organised multi-user Access application each user
will have their own copy of the front-end file and (ii) even if the user
can't rename the file 'cos someone else has it open, they can still copy it
in order to rename and rummage around in the copy.

Obviously this demands a degree of clever-dickery on the part of the user,
but then only clever-dick users are likely to want to rummage around in the
design anyway, so clearly it's exactly this kind of user that the OP is
concerned about. In an environment where the users are uninterested or
unable to look beneath the shortcut on their desktop, you've got nothing to
worry about anyway.

So why not go an extra stage and make it an accde file? You could even
rename that to accdr if you really thought it was worth it!

n.b. in my experience, because of bugs in Access 2007, it is actually
*essential* to deploy as an accde, but that's another story.

 

[bcap]

You are missing the point...

He doesn't want the users to play with the design wizards. They can
bugger
up an accde and mde with the design wizards. No design wizards are
available
in runtime mode.

Chris
Microsoft MVP

But (i) in any properly-organised multi-user Access application each user
will have their own copy of the front-end file and (ii) even if the user
can't rename the file 'cos someone else has it open, they can still copy
it
in order to rename and rummage around in the copy.

Obviously this demands a degree of clever-dickery on the part of the user,
but then only clever-dick users are likely to want to rummage around in
the
design anyway, so clearly it's exactly this kind of user that the OP is
concerned about. In an environment where the users are uninterested or
unable to look beneath the shortcut on their desktop, you've got nothing
to
worry about anyway.

So why not go an extra stage and make it an accde file? You could even
rename that to accdr if you really thought it was worth it!

n.b. in my experience, because of bugs in Access 2007, it is actually
*essential* to deploy as an accde, but that's another story.

Naming the file with the accdr extension is effective in many
environments
because when that clever person tries to rename it, he can't because

[quoted text clipped - 31 lines]

that's needed to get it to open in "full mode" is to rename in back to
ACCDB!

 

[Larry Linson]

He doesn't want the users to play with the design wizards.
They can bugger up an accde and mde with the design wizards.
No design wizards are available in runtime mode.

I thought it had already been established that changing one letter of the
file extension woul take it out of runtime mode? Did I miss something?

Larry

 

[Larry Linson]

AFAIK, the "things" which claim to turn an MDE
back into an MDB claim to recover the design of
your forms and reports, but they don't claim to
recover your code.

At least one does, and I have a report from someone whose opinion I trust
that it, in fact, does what it says it will do -- recover editable code --
from an MDE.

Not sure what you are getting at with your suggestion
of renaming an ACCDE file to ACCDE, I think you
might have made a typo. I was replying to the
suggestion that the OP renames his ACCDB file
to ACCDR.

No, not a typo, I simply misread and thought you were talking about ACCDE.
Sorry.

Larry Linson
Microsoft Office Access MVP

 

[bcap]

At least one does, and I have a report from someone whose opinion I trust
that it, in fact, does what it says it will do -- recover editable code --
from an MDE.

Presumably it would suffer from the same problem that has afflicted reverse
compilers since the dawn of time i.e. no meaningful identifiers, merely
unhelpful tokens?

 

[Larry Linson]

Presumably it would suffer from the same problem that
has afflicted reverse compilers since the dawn of time,
i.e. no meaningful identifiers, merely unhelpful tokens?

I was surprised to read that does not seem to be the case. As I said, I
have no need for such software, and little time to waste on pursuing
unnecessary information, so I did not obtain a copy and try it out. I do
not know if the third-party software works with Access 2007 ACCDEs, at all,
or the same.

The "compiled" output option may have been retained in Access 2007 for
performance rather than for security reasons. "Cracking" software
notwithstanding, I would generally recommend to my clients that the
front-end distributed to users be an MDE or an ACCDE, unless there were
compelling reasons to distribute an MDB or ACCDB. I have not done
applications for "general distribution", only "bespoke systems" for specific
clients' internal use, and it should be noted that I don't make any
recommendations regarding "general distribution" of Access database
applications.

With the exception of a couple of cases of consulting specifically on
security, in the days of Access 2.0 prior to the revelation of the
CopyObject flaw, my paying Access work has not used Access user and group
level security, but relied on server DB security to secure the data, or
permissions to users on the server shared folder. Where appropriate and
possible, the distributed front-end copy was compiled to MDE, and made
available in a shared folder, from which users could download a "good copy"
if "anything happened" to the copy of the front-end on the user's machine.

Larry Linson
Microsoft Office Access MVP

 

[bcap]

I was surprised to read that does not seem to be the case. As I said, I
have no need for such software, and little time to waste on pursuing
unnecessary information, so I did not obtain a copy and try it out. I do
not know if the third-party software works with Access 2007 ACCDEs, at
all, or the same.

The "compiled" output option may have been retained in Access 2007 for
performance rather than for security reasons. "Cracking" software
notwithstanding, I would generally recommend to my clients that the
front-end distributed to users be an MDE or an ACCDE, unless there were
compelling reasons to distribute an MDB or ACCDB. I have not done
applications for "general distribution", only "bespoke systems" for
specific clients' internal use, and it should be noted that I don't make
any recommendations regarding "general distribution" of Access database
applications.

With the exception of a couple of cases of consulting specifically on
security, in the days of Access 2.0 prior to the revelation of the
CopyObject flaw, my paying Access work has not used Access user and group
level security, but relied on server DB security to secure the data, or
permissions to users on the server shared folder. Where appropriate and
possible, the distributed front-end copy was compiled to MDE, and made
available in a shared folder, from which users could download a "good
copy" if "anything happened" to the copy of the front-end on the user's
machine.

Larry Linson
Microsoft Office Access MVP

I would add to that:

There is a bug in Access 2007 whereby large, complex forms can behave badly
in an accdb. When an afflicted form is opened in *form* view, closing the
form *invariably* results in a prompt to save design changes. I have
several forms which behave like this, and I have seen at least one other
person complain here of the same problem. I have attempted to deconstruct
an afflicted form in order to establish what causes the problem, but so far
without success (n.b. clicking "Yes" to the prompt results in no saved
design changes that I can discern!).

The only ways I have found to prevent this annoying (and puzzling to users)
prompt are to (i) make the file read-only (which results in an annoying nag
when the file is opened) or (ii) deploy it as an accde. Renaming to accdr,
as suggested above, would also work, but then I would lose the Home tab from
the ribbon, which I need to be available to users of this particular
application (I could of course build a custom home tab, but time is not on
my side!).

 

[bcap]

That's one method out of the three I mentioned for how to deploy a runtime
environment. Since accdbs are probably less than 1 or 2% of all Access
dbs
out there, it doesn't affect many dbs yet. Having that one method
unusable
in your specific environment doesn't rule out the other methods either.

Is it your position that no one should ever mention that renaming the
accdb
file to accdr opens the db in runtime mode or is it your position that
runtime mode won't prevent users from accessing the design wizards?
Runtime
mode might not work in every environment, but it would work very well in
my
environment for preventing the db users from changing the design. ymmv.

Chris
Microsoft MVP

My position is that if you've got users who are clued up enough to know (i)
that they are using an Access application (ii) that Access has such a thing
as design wizards and views and (iii) how to get at the design wizards and
views, then simply changing the file extension is unlikely to be a very
effective way of throwing them off the scent. So yes, my position *is* that
"runtime mode won't prevent users from accessing the design wizards",
because it's so easy for them to switch to "normal" mode.