disallow import from another mdb database

[Jay]

Is there a way to disallow another database from importing modules from my
database? I cannot use a mde solution, but I must lock up my code and I
cannot use object permissions because I do not want to activate the password
login. I have disabled the shift key and f11, so now the only way someone
could get to my code would be to import the modules into a blank database.
If I could disble this import, my code would be reasonably secure which is
all that I need.
Thanks for suggestions,

 

[Chris Mills]

Modules implies code, and the best way to protect code is mde's as you no
doubt know.

Why can't you use mde? The only reason I know of is that, mde prevents certain
types of Printer Selection which requires run-time design access. Though, most
of that can be achieved (the best you can get) by looking up "On-The-Fly
Printing".

If you don't want to activate a user signon, you can still implement Access
User Level Security (I think in this case it's limited to 2 levels). There are
posts by Joan Wild in this newsgroup on this subject, if she's not along soon!

If you can't use mde, can't activate User-level security, can't use object
permissions, then it begs the question "what CAN you do?"

Chris

It is very rare to not be able to use mde. I am one. But tell ME why YOU
can't. All I got from your post was that it's all too difficult. Which might
well be true )

 

[Jay]

The reason I cannot use an mde is because my application does
docmd.deleteObject which can only be done with mdb. Once you start using
this kind of object management in your applicaiton you effectively give up
the ability to use mde. It is very much a part of my app for which I cannot
substitute anything.
Thanks for the feedback.

 

[Chris Mills]

I think you could put code into an mde as an add-in.

 

[Jay]

Thanks again Chris. Could you please be more specific?
--
Jay

I think you could put code into an mde as an add-in.

 

[Chris Mills]

You can make an add-in module (aka a library database) mdb and then convert it
to an mde. You would place any code in it you want to hide. Then you add a
reference to the Add-in from your mdb and can call functions in it.

I'm not sure if this might be a bit messy if you are, say, manipulating
objects in the base mdb, but you should be able to transfer-out a lot of your
code as functions and protect it. There's no other way to protect it that I
know of.

There's a bit of help on Add-in's both in Access Help and VBA help (from a
code module).

Chris

 

[Joan Wild]

Deleting objects at runtime is a bit unusual. Why are you doing this -
perhaps there's a way to meet your goal without deleting objects.

 

[Jay]

My app is distributed among 400 customers in the internet zone. Everytime I
need to upgrade or fix the program, I have to cut a new CD and mail it out.
docmd.deleteObject allows me to avoid this by having a "smart client"
solution where the app downloads an mdb file with objects that replace
(delete, then add) forms, reports and modules in the local app. This way
the download is not the entire new app, just a small mdb file which has the
changed objects.
Thanks for your thoughts on this.

 

[Chris Mills]

That's pretty fancy Jay.

Does it compile and compact on-site as well? That's certainly essential when
design changes are made to a program.

I had a front-end getting up to about 40mB. But I didn't consider that, nor
would I. Too dangerous! To save what? Smaller on a CD?

Sure there's a size issue with internet downloads. Nevertheless, I've found it
necessary (or desirable) to thoroughly TEST a new front end before
distributing it. The slightest change could cause a corruption, for all anyone
knows.

Maybe it's OK. I haven't read of anyone really doing it that way.

and...where's their backup? I mean, if down-the-track my FE gets corrupted for
any reason, I can get them to re-load the FE from CD. Not the BE of course. Do
FE's get corrupted in use? Yes, though not very often I admit.

I distributed an mdb which allowed printer design-changes (before mde's were
available). I regret it, because it's damn hard to remove functionality from a
customer! (the app could work anyway, but I gave them this fancy stuff). I
regret it because, I can't implement mde!

So you have a choice. Is this more important than security of your code? At
the time I did my stuff, Access Security wasn't such an issue (at least...so I
thought...)

But hey, good on you! No-one would know how well it works if someone didn't
try it!

Chris

 

[Chris Mills]

How do you track mdb version?

I know that my version x.y FE is nnn bytes on CD, as distributed.

Of course, the version number (of my s/w) should be sufficient. But I can
check by actual byte-count too. Customers will SWEAR they have done something!

You CANNOT EVER say that your FE on one site is identical to another site's,
nor even your original development/test FE.

Or can you?

 

[Jay]

Wow Chris, your corruption issue is quite scary. We have been releasing FE
mde software for 8 years to accounting professionals. Not one time did we
ever find that some customer’s FE was different than another's, at least not
in terms of the execution. Now we are going to move away from mde toward mdb
so as to allow for the object management. We do not anticipate corruption
problems caused by customers messing with the app - we disable the shift key
and the pf11 key.
I pray I am not being naive about the potential corruption.
As for tracking version, I just follow an "upgradeTicket" table in the
download file with the objects to be replaced. All controlled by a release
sequence number driven by changes approprite to the base release.

 

[Chris Mills]

Wow Chris, your corruption issue is quite scary.

Oy, life is scary. I don't mean to emphasize FE Corruption, which I think I
said is rare when "running", however it's common when "designing" (A2k, A2k2).
I'd regard your site-replacement scheme as "designing on-site" in a technical
sense.

Cheers
Chris

 

[Mark Vanderslice]

Jay,

My group distributes compiled Access apps to 700+ education entities for
budget and financial reporting to the state gov't. We have used a FE/BE
approach for years--all user tables in BE, all other components in FE. Any
tables of reference data, system controls and parameters, etc. are also in
FE. FE is always compiled into .mde.

The source FE.mdb has the VBA project password-protected (vb editor, tools,
project properties, protection tab, "lock project for viewing" checked,
enter and confirm password).

I know this prevents importing. Anytime I want to import a module to another
app, I have to make a copy of the .mdb with the code, open the copy, open
project in VB ed. with the password, then uncheck locked, and remove
password, before I can import a module to another app.

I'm using Office 2000 pro, Win 2000, but I think this is pretty much the
same in later Access versions as well.

Like the other posters, I would never release an app as .mdb. We have to
many clever tech support people at schools who try to hack and override our
calculations, validations, etc. etc. just for fun. For our apps, the BE is
..mdb (not .mde), but it's also password-protected. In the FE, the user has a
"relink" button, and in that code the connect string passes the password
when relinking to a different or new BE. Since the FE code is compiled, no
one can see the BE password.

We've been doing this for about seven years on three or four major apps a
year, and I have yet to have anyone break into a FE or BE, or get at VBA.
Not saying it's perfect, but it's pretty airtight.

Also, when neede, we've added and updated tables in the backend, by running
code from the compiled FE. I'd have to dig around to find the code, but I
think it involves opening a copy of the backend as an Access object, then
running the commands to add/update the required objects, then saving it,
delete old BE copy, rename new BE as old BE. We did this because it was
critical to preserve data users had already entered into the app.

We release FE updates as self-extracting WinZip .exes that simply extract
the new FE version to the expected folder location, overwriting the old
version. Users are instructed at startup to click a "Run Updates" button on
main menu. This executes any required code to update BE tables/records, or
if needed, add/change BE objects. Sometimes we don't have any BE updates,
but users are always told to click the button anyway; if all the version
changes are in the FE, the button simply displays the "updates installed"
message. No harm done and the users feel warm and fuzzy about the process.

Hope this helps...

 

[John Mishefske]

Jay,

My group distributes compiled Access apps to 700+ education entities for
budget and financial reporting to the state gov't. We have used a FE/BE
approach for years--all user tables in BE, all other components in FE. Any
tables of reference data, system controls and parameters, etc. are also in
FE. FE is always compiled into .mde.

The source FE.mdb has the VBA project password-protected (vb editor, tools,
project properties, protection tab, "lock project for viewing" checked,
enter and confirm password).

I know this prevents importing. Anytime I want to import a module to another
app, I have to make a copy of the .mdb with the code, open the copy, open
project in VB ed. with the password, then uncheck locked, and remove
password, before I can import a module to another app.

I'm using Office 2000 pro, Win 2000, but I think this is pretty much the
same in later Access versions as well.

Like the other posters, I would never release an app as .mdb. We have to
many clever tech support people at schools who try to hack and override our
calculations, validations, etc. etc. just for fun. For our apps, the BE is
.mdb (not .mde), but it's also password-protected. In the FE, the user has a
"relink" button, and in that code the connect string passes the password
when relinking to a different or new BE. Since the FE code is compiled, no
one can see the BE password.

You might be interested in checking that with SysInternal's String utility (which mimics
the unix String command).

http://www.sysinternals.com/Utilities/Strings.html

If your connection string is a String it will be found in an .mde file. Most String values
will be found. Granted not many folks know that....

However, a quick workaround is to use concantenation to store the password:

Dim pwd As String
pwd = "m" & "m" & "y" & "P" & "a" & "s" & "s"

This isn't a fix but will prevent Strings from seeing it.