How do I set in a code in VBA the startup feature of MS Access?

[Guest]

I finished a project in MS Access 2003. I want to secure it by coding a VBA
to set off all the options of the StartUp instead of setting it manually.
Besides, if I set it manually, I can't find a way to re-set it again. This
leads me to unusable database.

Please help me. I really appreciate your time giving me the solution. Thank
you.

Sincerely,
Rody

 

[TC]

Can't be done - because some of those options do not take effect until
the /next/ open.

For example, you can turn the "bypass shift key" option off, on
startup, through VBA code - but there is no point in doing so, because
it only affects the /next/ open - not the /current/ open - so the user
might have bypassed your startup options /already/.

You can never get locked-out (and be unable to set the options back),
unlkess you loose the workgroup file that was in effect when you
created the database. Any member of the Admins group of that workgroup
file, can set the options back, at any time.

HTH,
TC

 

[Guest]

Dear TC,

Thanks a lot for your advice and your time responding to my query. I did not
set a workgroup file as my application is not intended for a multi-user use.
I am going to distribute my "Split Database" Front-end to the user who is
going to use the application report. My concern here is to secure my
"Back-End Database" so if anyone steal the database, they can't modify
anything from it. I know setting the workgroup file is the least solution but
I dont want user annoyed by the log-on everytime they use the application,
since I created the log-on form specific for the users using the application
report and the one who is using actually the application.

I remember one time, I used the code and it works but unfortunately, the
source code was lost. If I set off manually all the options, the next time I
run the application, without this VB code(to reset back to ON all the
options) then, I don't have a way to access back all the toolbars and the
database as a whole.

I hope you can help me with this... Thanks a lot.

Rody

 

[TC]

Hi Rody

My comments in-line.

Thanks a lot for your advice and your time responding to my query.

No probs, glad to help if I can.

I did not set a workgroup file as my application
is not intended for a multi-user use.

Access /always/ requires a workgroup file - in every case, without
exception. When you install it, it creates a default workgroup file,
system.mdw. That is probably what you are using. If you have not taken
any steps to impose "user level security" on your database, then, your
database will probably work with the default system.mdw of any other
Access installation.

I am going to distribute my "Split Database" Front-end to the user who is
going to use the application report. My concern here is to secure my
"Back-End Database" so if anyone steal the database, they can't modify
anything from it.

Ok. You want to stop people going directly into the back-end database,
using Access, and viewing or changing the tables directly, bypassing
the front-end forms and reports completely. Correct? If so, there is
really no way to do it. If you /don't/ have "user level security",
someone can just copy the back-end database, & open it with their copy
of Access. If you add user-level security, they just have to copy the
workgroup file as well, and log-on with their known username/password.

Of course, a small effort will keep 99% of users out. So maybe, adding
user-level security would be enough. 99% of users probably would not
know to copy the workgroup file. So they'd just copy the database, and
then be unable to open it on their PC.

Unfortunately, user-level security is difficult to learn (initially),
and you must follow a documented sequence of steps, in exact detail, or
it just won't work. Get the "Access security FAQ", often referenced on
this newsgroup, if you need more information about it.

I know setting the workgroup file is the least solution but
I dont want user annoyed by the log-on everytime they use the application,
since I created the log-on form specific for the users using the application
report and the one who is using actually the application.

But why would /your/ logon form bother them less that the /standard/
one? And, your logon form will not prevent them going directly into the
back-end file.

I remember one time, I used the code and it works but unfortunately, the
source code was lost. If I set off manually all the options, the next time I
run the application, without this VB code(to reset back to ON all the
options) then, I don't have a way to access back all the toolbars and the
database as a whole.

Someone (I foget who) has a convenice tool to help you turn the options
off & on. Some googling in this group may find it for you.

Cheers,
TC
(off for the day)

 

[Guest]

Hi TC,

Thanks a lot for your advice. Since my application is not intended for
multi-user, I would like to go through the process I want to have on my
back-end database.

If I set off manually all the startup options, would it be opened and
restored back again through new mdw file? or when installed new ACCESS the
next time it opened? If it is, then it's useless for me to ask the question
here... Else, the code will be the only way I can go back to whole authority
of my database.

If you can help me refer my problem to be solve as early as possible since I
want to deploy my application the soonest. I can't help deploying the
back-end database unsecured.

Thanks for you help. I really appreciate others that would come and help me.

Regards,
Rody

 

[Joan Wild]

Dear TC,

My concern here is to secure my
"Back-End Database" so if anyone steal the database, they can't modify
anything from it.

You could put the backend in a hidden folder \\servername\share$ rather than
\\servername\share They won't see the folder in Windows Explorer, but they
could still get to it *if* they know the path.
You could create an autoexec macro in the backend that throws up a message
(or not) and then closes Access.
You could disable the shiftkeybypass in the backend.

That might be enough to discourage your users.

Albert Kallal has a utility you can use to switch it on/off 'By Pass Shift
Key Code' at
http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

I know setting the workgroup file is the least solution but
I dont want user annoyed by the log-on everytime they use the application,

It is possible to secure it so that it doesn't require a logon.

If I set off manually all the options, the next time I
run the application, without this VB code(to reset back to ON all the
options) then, I don't have a way to access back all the toolbars and the
database as a whole.

You can use Albert's utility to switch the shiftkey back on. Another
thought is that you keep your copy of the frontend with the shiftkey
enabled. Copy it, and on the copy disable the shiftkey and distribute it to
your users.

 

[TC]

If you do not add user-level security to the database, then, anyone who
knows how should be able to turn off all the startup options, and get
in to it.

Joan has some good suggestions which would probably deter all but the
most diligent users.

HTH,
TC

 

[Guest]

To Joan and TC and Albert,

Guys you are really a handful of three. I really appreciate your advices
which helped me a lot in my query.

Although my users are not that "Power Users" as both of you, using the
utility you mentioned helped me to discourage my users in inadvertently
modifying in my Back-End database. I know bypassing the shift key is not what
we called a secured database, but in lighter side of the end-user, they
"think" it is well secured.

Joan, I downloaded your step by step security and followed them. Everything
works as expected using the new workgroup file. But when I joined again the
default system.mdw, it turned out to be unsecured. I can still open as
nothing has happened. What seems to be the problem here? Did I missed
something?

I tried to secure my back end database but it seems the security
persmissions wasn't applied. What if someone copied the back-end databse and
opened it on their copy of Access, absolutely they owned again the
permissions.

Thanks a lot for all your untiring advices.

Rody

 

[Joan Wild]

Joan, I downloaded your step by step security and followed them.
Everything
works as expected using the new workgroup file. But when I joined again
the
default system.mdw, it turned out to be unsecured. I can still open as
nothing has happened. What seems to be the problem here? Did I missed
something?

I'm confused. You wanted to secure it, but not require that users login.
That means you secure it with a separate mdw, but you give permissions (as
limited as you wish) to the Users Group. You then ship your mdb without the
secure mdw. When the users use the mdb, they'll use their standard
system.mdw. They'll get no login, but they will be restricted by the
permissions you set on the Users Group. So of course they'll be able to
open it.

 

[Guest]

Joan,

Thanks for your reply. Actually, I have never wanted to secure my back-end
database, that's why I posted here how could I code the startup. And you did
helped me. My problem was solved.

I am just wary how security permissions be applied when creating a new mdw.
That's why I downloaded your step by step as this is easy to follow rather
than the MSACCESS FAQ. Pls. refer again to my previous post. Did I missed
something?

Thanks a lot for your advices...

Rody

 

[Joan Wild]

Joan,

Thanks for your reply. Actually, I have never wanted to secure my back-end
database, that's why I posted here how could I code the startup. And you
did
helped me. My problem was solved.

I am just wary how security permissions be applied when creating a new
mdw.
That's why I downloaded your step by step as this is easy to follow rather
than the MSACCESS FAQ. Pls. refer again to my previous post. Did I missed
something?

I can't possibly know what step you missed. You are following not just the
stepbystep, but also the instructions at
http://www.jmwild.com/SecureNoLogin.htm right?

 

[Guest]

Joan,

Thanks for your reply. Yes, I followed your step guide from 1-15, then
22-32. Followed too, the instruction "If you followed steps 1-15, it is
recommended you do..." I followed steps 1-3 and the remaining instructions.
It is working. As a final test as you said, when double clicking the secured
database, I can still open it without the log-on password. Meaning, it seems
the security wasn't applied.

I tried two times to re-create a NEW mdw just to test again. But the same
I've got. Thanks for your time again...


Rody

 

[TC]

To Joan and TC and Albert,
Guys you are really a handful of three.

For your album:

http://www.uwrf.edu/animal-science/Images/3Bud.gif


TC

 

[Guest]

Hi TC,

I wonder you three are really working together, or perhaps you are friends
by the way?

Well, thanks for your help. I really appreciate it. I hope I can get back to
you again.

God Bless You all!

Rody

 

[TC]

No probs, glad I could help.

I only know Joan & Albert by their posts in this newsgroup (and vice
versa).

I just thought the three horses looked neat!

Cheers,
TC

 

[Guest]

Yes indeed, they are cute and lovely. They convey friendship...

Have a great day!!!

Rody

 

[Joan Wild]

Joan,

Thanks for your reply. Yes, I followed your step guide from 1-15, then
22-32. Followed too, the instruction "If you followed steps 1-15, it is
recommended you do..." I followed steps 1-3 and the remaining
instructions.
It is working. As a final test as you said, when double clicking the
secured
database, I can still open it without the log-on password. Meaning, it
seems
the security wasn't applied.

Not necessarily. That means that you can open it using the default
system.mdw *which is what you want*. You don't want to have a login. So
what is the problem? For example, if you denied the Users Group delete
permissions on some table. Can you, using the system.mdw, delete a record
in that table?

If not, then it is working as it's supposed to.