For many years I've been delivering Access 97 applications with a
referenced library mdb. The library contains custom logic for each
client. When the custom logic is modified, I send the client a new
version of the library.

I've been securing the main and library databases using user-level
security. Now I'm converting the applications to Access 2002, and
according to the postings I've read, it seems that I can no longer make
my system work:

- Modules can no longer be secured with user-level security
- Securing code with an IDE password is not secure
- Mde libraries can't be updated without compiling the main mde

It would be very inconvenient to have to recompile and deliver the main
app every time I modify custom logic. But it seems my code won't be
secure unless I use mdes. Is this correct? Any suggestions?

Thanks,

Jerry

The library can be an MDE. The main app doesn't have to
be, unless it has code in it as well.

The IDE password is not particularly insecure, compared with
anything else in access.

Your library MDE can be secured with user level security.
You can't put user level security on individual code modules,
but you can put user level security on the MDE.

MDE's aren't particularly secure either. MDE security was
downgraded in A2000, and you can recover most if not all
of the code. You can use a code obscurer if you want better
than that.

(david)


"Jerry Porter" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> For many years I've been delivering Access 97 applications with a
> referenced library mdb. The library contains custom logic for each
> client. When the custom logic is modified, I send the client a new
> version of the library.
>
> I've been securing the main and library databases using user-level
> security. Now I'm converting the applications to Access 2002, and
> according to the postings I've read, it seems that I can no longer make
> my system work:
>
> - Modules can no longer be secured with user-level security
> - Securing code with an IDE password is not secure
> - Mde libraries can't be updated without compiling the main mde
>
> It would be very inconvenient to have to recompile and deliver the main
> app every time I modify custom logic. But it seems my code won't be
> secure unless I use mdes. Is this correct? Any suggestions?
>
> Thanks,
>
> Jerry
>

Thanks for the reply, David.

>> The library can be an MDE. The main app
>> doesn't have to be, unless it has code in it as well.

The main app has a lot of code. I'm more concerned about securing the
main app than the library. Making it an mde would make me unable to
update the library.

>> You can't put user level security on individual code modules,
>> but you can put user level security on the MDE.

Are you saying that the modules as a whole can be secured? Does this
apply to an mdb as well? If so, how is this done?

>> You can use a code obscurer

I don't find any links for this. Can you point me to something?

Thanks again,

Jerry

david@epsomdotcomdotau wrote:
> The library can be an MDE. The main app doesn't have to
> be, unless it has code in it as well.
>
> The IDE password is not particularly insecure, compared with
> anything else in access.
>
> Your library MDE can be secured with user level security.
> You can't put user level security on individual code modules,
> but you can put user level security on the MDE.
>
> MDE's aren't particularly secure either. MDE security was
> downgraded in A2000, and you can recover most if not all
> of the code. You can use a code obscurer if you want better
> than that.
>
> (david)
>
>
> "Jerry Porter" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > For many years I've been delivering Access 97 applications with a
> > referenced library mdb. The library contains custom logic for each
> > client. When the custom logic is modified, I send the client a new
> > version of the library.
> >
> > I've been securing the main and library databases using user-level
> > security. Now I'm converting the applications to Access 2002, and
> > according to the postings I've read, it seems that I can no longer make
> > my system work:
> >
> > - Modules can no longer be secured with user-level security
> > - Securing code with an IDE password is not secure
> > - Mde libraries can't be updated without compiling the main mde
> >
> > It would be very inconvenient to have to recompile and deliver the main
> > app every time I modify custom logic. But it seems my code won't be
> > secure unless I use mdes. Is this correct? Any suggestions?
> >
> > Thanks,
> >
> > Jerry
> >

> >> You can use a code obscurer
>
> I don't find any links for this. Can you point me to something?

The code delivery tool from fms:
http://www.fmsinc.com/products/CodeTools/index.html

or code protector from everythingaccess:
http://www.everythingaccess.com/mdeprotector.htm

We moved everything out of our base module, but you're
right, you need to ship the whole mde chain if you change
an mde.

We have user level security on our mdb/mde which prevents
enabling the database window and the special keys: there is
no easy way to get to the code project even if you open
the database: there are no enabled menu's, key strokes or
windows to take you their, and you can't turn them on
without user-level database admin permission. And you
can't give your self database admin permission unless you
are a member of the admins group, which we don't ship.

(david)


"Jerry Porter" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thanks for the reply, David.
>
> >> The library can be an MDE. The main app
> >> doesn't have to be, unless it has code in it as well.
>
> The main app has a lot of code. I'm more concerned about securing the
> main app than the library. Making it an mde would make me unable to
> update the library.
>
> >> You can't put user level security on individual code modules,
> >> but you can put user level security on the MDE.
>
> Are you saying that the modules as a whole can be secured? Does this
> apply to an mdb as well? If so, how is this done?
>
> >> You can use a code obscurer
>
> I don't find any links for this. Can you point me to something?
>
> Thanks again,
>
> Jerry
>
> david@epsomdotcomdotau wrote:
> > The library can be an MDE. The main app doesn't have to
> > be, unless it has code in it as well.
> >
> > The IDE password is not particularly insecure, compared with
> > anything else in access.
> >
> > Your library MDE can be secured with user level security.
> > You can't put user level security on individual code modules,
> > but you can put user level security on the MDE.
> >
> > MDE's aren't particularly secure either. MDE security was
> > downgraded in A2000, and you can recover most if not all
> > of the code. You can use a code obscurer if you want better
> > than that.
> >
> > (david)
> >
> >
> > "Jerry Porter" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > For many years I've been delivering Access 97 applications with a
> > > referenced library mdb. The library contains custom logic for each
> > > client. When the custom logic is modified, I send the client a new
> > > version of the library.
> > >
> > > I've been securing the main and library databases using user-level
> > > security. Now I'm converting the applications to Access 2002, and
> > > according to the postings I've read, it seems that I can no longer
make
> > > my system work:
> > >
> > > - Modules can no longer be secured with user-level security
> > > - Securing code with an IDE password is not secure
> > > - Mde libraries can't be updated without compiling the main mde
> > >
> > > It would be very inconvenient to have to recompile and deliver the
main
> > > app every time I modify custom logic. But it seems my code won't be
> > > secure unless I use mdes. Is this correct? Any suggestions?
> > >
> > > Thanks,
> > >
> > > Jerry
> > >
>

These tips are very helpful, David. Thanks!

Jerry

david@epsomdotcomdotau wrote:
> The code delivery tool from fms:
> http://www.fmsinc.com/products/CodeTools/index.html
>
> or code protector from everythingaccess:
> http://www.everythingaccess.com/mdeprotector.htm
>
> We moved everything out of our base module, but you're
> right, you need to ship the whole mde chain if you change
> an mde.
>
> We have user level security on our mdb/mde which prevents
> enabling the database window and the special keys: there is
> no easy way to get to the code project even if you open
> the database: there are no enabled menu's, key strokes or
> windows to take you their, and you can't turn them on
> without user-level database admin permission. And you
> can't give your self database admin permission unless you
> are a member of the admins group, which we don't ship.
>
> (david)

David,

I'm assuming you prevent access to the IDE by disabling menus and
special keys in the Startup options, and then using code based on user
security to enable them.

(Properties: AllowSpecialKeys, AllowFullMenus, AllowShortcutMenus,
AllowToolbarChanges, AllowBuiltInToolbars).

Is this right?

Jerry

david@epsomdotcomdotau wrote:
> We have user level security on our mdb/mde which prevents
> enabling the database window and the special keys: there is
> no easy way to get to the code project even if you open
> the database: there are no enabled menu's, key strokes or
> windows to take you their, and you can't turn them on
> without user-level database admin permission. And you
> can't give your self database admin permission unless you
> are a member of the admins group, which we don't ship.

After working on this a bit, I realized:

1) I only need to turn off these properties when I create the
deliverable, though I will include a way to reenable them in the
deliverable for debugging.

2) I left out the most important property in my previous post:
AllowBypassKey
If that's not disabled, holding the Shift key at startup bypasses the
disabling of all the other features.

Jerry

Jerry Porter wrote:
> David,
>
> I'm assuming you prevent access to the IDE by disabling menus and
> special keys in the Startup options, and then using code based on user
> security to enable them.
>
> (Properties: AllowSpecialKeys, AllowFullMenus, AllowShortcutMenus,
> AllowToolbarChanges, AllowBuiltInToolbars).
>
> Is this right?
>
> Jerry
>

You need to have database admin permission to change the
database properties. Note that some of the sample code for
AllowBypassKey does not create a database property which
requires database admin permission to change - you need to
refer to sample code which explicitly does this.

When we want to change database properties, we log in as
a user who has database admin permission.

Control of permissions is controlled by the admins group, but
we don't normally switch permissions around, we just log in
as the user which has those permissions.

(david)


"Jerry Porter" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> After working on this a bit, I realized:
>
> 1) I only need to turn off these properties when I create the
> deliverable, though I will include a way to reenable them in the
> deliverable for debugging.
>
> 2) I left out the most important property in my previous post:
> AllowBypassKey
> If that's not disabled, holding the Shift key at startup bypasses the
> disabling of all the other features.
>
> Jerry
>
> Jerry Porter wrote:
> > David,
> >
> > I'm assuming you prevent access to the IDE by disabling menus and
> > special keys in the Startup options, and then using code based on user
> > security to enable them.
> >
> > (Properties: AllowSpecialKeys, AllowFullMenus, AllowShortcutMenus,
> > AllowToolbarChanges, AllowBuiltInToolbars).
> >
> > Is this right?
> >
> > Jerry
> >
>