hide all data base object

  • Thread starter Thread starter a
  • Start date Start date
A

a

Is possible to hide all data base object by code using VBA to prevent user
from importing my forms or my tables or query or reports?

I need just hide?

Thank you
 
If the person knows the object exists, they can import it even if it is
hidden. You can either distribute only the mdb version or apply a password.
Be aware there are several Access password crackers available on the web.
 
Thank for your help and reply:

1- How can they import object and it doesn't appear?

I know I can import object if it hidden…by using right click on the object
and select hide (attributes) (he) can Import the object because he can set
show object = true in his database

But If we do that with VBA can he Import the object?

Notes:

I think the user of my data base not are power user ?

I'm just need to hide access object by using vba

I will tell you the reason of hidden my data base object

I will distribute my data base without setting password in VBA for one
reason

The reason:

I will use CopyObject to copy forms; reports; query ;tables; macro to
another data base

This is the only way for me
 
Well, if they don't know Access very well, they can't import, but you can
with vba.
Why not just distribute an mde?
 
Thank you for your reply

I can't distribute my data base as mde because:

I will tell you:

I will create (another data base) from my original data base!

I will use CopyObject to copy object to (another data base)the second data
base

Objects is:

Forms; reports; macro;module;query

For special purpose I don't want :

The second data base (another data base) as mde
 
You most certainly can, and should hide all of the ms-access interface. The
options to complete hide and keep people out of the ms-access interface can
easily be done using the tools->start-up options. Using those options allows
you to complete hide the ms-access interface (tool bars, database window
etc). Also, using these options means you
do not have to bother setting up security.

Try downloading and running the 3rd example at my following web site that
shows a hidden ms-access interface, and NO CODE is required to do
this....but just some settings in the start-up.

Check out:

http://www.members.shaw.ca/AlbertKallal/msaccess/DownLoad.htm

After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.
You can get this at:
http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html
 
Thank you for your help and answer

I do what you say exactly :

Because I love working without code

My big problem is how to hide the forms in my database because I don't want
use VBA Password or MDE.

Also I don't want hide using (hide attributes) because user can easily
import the forms or access objects.

The reason :

I will use CopyObject to copy Forms to (another data base)
 
My big problem is how to hide the forms in my database because I don't
want use VBA Password or MDE.
Click to expand...

Well, the VBA password is 100% useless and not secure.

You could consider using ms-access security (that is NOT to be confused with
VBA passwords). Security can be broken, but certainly not by the average
user....

The *best* solution here is to usually deploy a mde (it not clear why you
have an adversion to using a mde).

If you don't choose one of the above 2 approaches (mde, or security), then
you have absolute zilch to work with here.

Why not just use and deploy a mde? A mde also loads faster, runs faster,
does not become un-compiled etc. (this list just goes on quite a few
benefits).

Simply deploy new mde's for each new update, or form, or report you need to
add the application.

I explain the concept of splitting your database here, and when your db is
split...you simply issue new executables (mde), and you not have to
touch/change the data for the application.

http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
 
Back
Top