Database encyrption?

[Scott Loupin]

I've got a database I want to sell. The potential buyers want a copy of the
database, for a trial. I'm afraid they'll copy all the modules, rename and
reformat a few forms, and call it theirs.

How can I hide all the background information while still giving them use of
the database?

Any way to disable the Shift key when opening the database?

Thanks,

Scott

[Bruce M. Thompson]

> I've got a database I want to sell. The potential buyers want a copy of the

database, for a trial. I'm afraid they'll copy all the modules, rename and
reformat a few forms, and call it theirs.

If you convert the MDB to an MDE file, there will be no access to the code or
the design of any object that can contain code.

--
Bruce M. Thompson, Microsoft Access MVP
bt******@mvps.org (See the Access FAQ at http://www.mvps.org/access)

NO Email Please. Keep all communications

within the newsgroups so that all might benefit.<<

[Scott Loupin]

Hi Bruce;

I tried it, I can lock out reports, forms and modules, but not tables,
queries, or relationships. I'm especially concerned about relationships.
Any ideas?

Thanks for the help!

Scott

If you convert the MDB to an MDE file, there will be no access to the code or the design of any object that can contain code.

--
Bruce M. Thompson, Microsoft Access MVP
bt******@mvps.org (See the Access FAQ at http://www.mvps.org/access)

NO Email Please. Keep all communications

within the newsgroups so that all might benefit.

[Mike Storr]

I don't see how relationships are that important to protect. Anybody with a
good working knowledge of tables and normalization could re-create them (or
at least create their own that work in a similar manner). The processing and
interface, I feel, are more important to protect than the joins and storage
as these are the things that require most of your time in development.

Mike Storr
www.veraccess.com
"Scott Loupin" <Sc************************@verizon.net> wrote in message
news:HT****************@nwrddc01.gnilink.net...

Hi Bruce;

I tried it, I can lock out reports, forms and modules, but not tables,
queries, or relationships. I'm especially concerned about relationships.
Any ideas?

Thanks for the help!

Scott

If you convert the MDB to an MDE file, there will be no access to the

code or

the design of any object that can contain code.

--
Bruce M. Thompson, Microsoft Access MVP
bt******@mvps.org (See the Access FAQ at http://www.mvps.org/access)

> NO Email Please. Keep all communications

within the newsgroups so that all might benefit.

[Peter Miller]

Mike,

On Fri, 30 Jan 2004 14:35:35 -0500, "Mike Storr"
<no****@somewhere.con> wrote in comp.databases.ms-access:

I don't see how relationships are that important to protect...

In general, of course, you're right.

But I suspect that as part of an effort to protect the db, the OP has
used generic field and table names. For example, tblInvoice,
tblInvoiceDetail and tblSalesperson are instead named tblA, tblB, tblC
etc. and have fields (a,b,c,d,e,f), (a,b,c,d) and (a,b,c).
Relationships show that tblA.e ties to tblC.c and tblA.c ties to
tblB.b. Obfuscation is pretty limited in effectiveness, especially if
relationships are visible. By preventing relationships from being
seen, it's not clear with the range of values in tblA.c being from
1..25 which other table it may relate to.

I'm not advocating such a setup. In fact, i think it violates all
sorts of good design principles. But its effectiveness is most
seriously hampered by relationships being visible (well, among other
things), so perhaps that's why the OP wants to protect relationships.

I just thought I'd throw it out there as a possible implementation
where something that normally has little value in terms of a security
mechanism might actually take on more prominence under a specialized
case.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051

[Bruce M. Thompson]

> I tried it, I can lock out reports, forms and modules, but not tables,

queries, or relationships. I'm especially concerned about relationships.
Any ideas?

Well, if you must, you can set the "AllowBypassKey" property to False with code
available in Access Help or using a utility available at Albert Kallal's web
site:

http://www.attcanada.net/~kallal.msn.../msaccess.html

Scroll down to the section titled "By Pass Shift Key Code" to find the links.

--
Bruce M. Thompson, Microsoft Access MVP
bt******@mvps.org (See the Access FAQ at http://www.mvps.org/access)

NO Email Please. Keep all communications

within the newsgroups so that all might benefit.<<

[Mike Storr]

If encryption were implemented, and the obscurity of the meaning of the data
and it's relations were important, I would agree with you (eg personal info
security). But this brings in complications with maintence that I don't
think most people care to get into. Person A designs a system in order to
prevent Person B from interpreting it. Person A gets fired, or is no longer
around, and nobody understands it anymore. The documentation of the project
would need to be flawless in order for a newcomer to take over (I'm sure
that is really common too). Sometimes I think that if security is that
important, Access is not the tool to build with.
"Peter Miller" <pm*****@pksolutions.com> wrote in message
news:ba********************************@4ax.com...

Mike,

On Fri, 30 Jan 2004 14:35:35 -0500, "Mike Storr"
<no****@somewhere.con> wrote in comp.databases.ms-access:

I don't see how relationships are that important to protect...

In general, of course, you're right.

But I suspect that as part of an effort to protect the db, the OP has
used generic field and table names. For example, tblInvoice,
tblInvoiceDetail and tblSalesperson are instead named tblA, tblB, tblC
etc. and have fields (a,b,c,d,e,f), (a,b,c,d) and (a,b,c).
Relationships show that tblA.e ties to tblC.c and tblA.c ties to
tblB.b. Obfuscation is pretty limited in effectiveness, especially if
relationships are visible. By preventing relationships from being
seen, it's not clear with the range of values in tblA.c being from
1..25 which other table it may relate to.

I'm not advocating such a setup. In fact, i think it violates all
sorts of good design principles. But its effectiveness is most
seriously hampered by relationships being visible (well, among other
things), so perhaps that's why the OP wants to protect relationships.

I just thought I'd throw it out there as a possible implementation
where something that normally has little value in terms of a security
mechanism might actually take on more prominence under a specialized
case.

Peter Miller
__________________________________________________ __________
PK Solutions -- Data Recovery for Microsoft Access/Jet/SQL
Free quotes, Guaranteed lowest prices and best results
www.pksolutions.com 1.866.FILE.FIX 1.760.476.9051