Hiding the Access 2013 Application during database use...

[sooli]

how in the world do i hide the database window? The thing takes up the whole screen, all my users need are the forms I created... used to be a check box that would let you not display the application... that feature seems to be gone in 2013 =/

[Brilstern]

sooli,

Assuming you login with a unique username you can set form properties on load.

Example: (pseudo code)

If Me.Username = "Admin" Then
Me.Control.Visible = true
Else
Me.Control.Visible = False
End If

This button could allow for a close option for you.

To answer your other question:
Set the On Close Event to quit the database. This would force the database to close if a user uses the close in the navigation.

Another option would be to disable the close in the navigation altogether in the form properties. This would force the user to log out.

[twinnyfo]

@sooli,

When I create my DBs, I always do this:

1. There is always a Front-End/Back-End structure, so the DATA is always separated from the CODE. If your Front-End (the Code) crashes, then you don't lose your data. The data side very seldom (if ever) crashes.
2. When the Front end if opened, it checks to see how long it has been since the DB has been updated. My schedule is every six hours. If it has been six hours, the DATA is backed up again (just in case the data does crash).
3. My shortcut does not point to the DB itself, but to a MS Scripting file, which copies the DB to the local user's machine. If the local version crashes, it does not corrupt the master copy of the front-end.
4. My Front-End is ALWAYS compiled (.accde or .mde file), so no one can access the code or modify any of the objects.
5. All navigation controls are disabled in the DB (including the Nav pane, shortcut menus, etc.). I have not found an effective method for bypassing the "Shift-Key" method. Any experts out there know a simple way to do this?
6. My DBs log who has accessed the DB and assigns permissions to the user that I establish. Each user can only see what I let them see.
7. All forms are locked down (no built in controls, like Minimize, maximize and close). My users can only do what I want them to do with the forms. Navigation ultimately leads them to either do their job or exit the DB.

I use these principles because people are inherently inquisitive and like to snoop around DBs. I do everything I can to prevent this.

Here are some links to a couple articles that may assist in these tasks:

Working with Front-Ends and Back-Ends

MS Access User Permissions

[Brilstern]

Nice business rules twinnyfo. Going to have to put those in the toolbox for future projects.

[twinnyfo]

@Stevan,

I have been DBasing for about 20 years, and, unfortunately, I learned just about everything I know via bad experience. Up until maybe 5-6 years ago, I did not know what DB normalization was. I practiced those principles almost exclusively, but it was not because I was taught the principles. I learned--by creating poorly designed DBs--that there were certain principles that made for a better design. Now I am able to talk intelligently about those principles.

Thanks to this site, primarily, I have learned much more about good design and programming concepts that have both re-inforced many practices and corrected some others. I want to spare others my bad experiences by guiding these young Jedis in the good ways of the Force.

I don't know what experience you have, but thanks for joining us!

[Brilstern]

@twinnyfo,

Now that we have successfully hijacked sooli's thread (hah just joking!) we appreciate the willingness of those that know to pass on the information.

I built my first database in 2011 and have found myself building one here and there ever since. My goal is always to make my next DB better than my last. Bytes has truly helped me do that!

[sooli]

@twinnyfo,

I would love to create the .accde! but it seems access 2013 doesn't afford that luxury. Or I need an addin that I don't know about. I guess when they took away the ability to hide the database with a check box in the database properties, they also removed that feature. The .accde is the one that actually keeps the users from being able to get to the database itself, or make changes to the forms.. i have all that locked down to an extent - but as you are aware... curiosity can lead to sneaky back door access... My boss didn't want the database to have a password to access it, so I was careful to create my own switch with nothing other than what the users are supposed to be able to do, and a password protected menu for administration which is reached thru a cmd button. The database is split so the user only has the front end, and so far I have only had one nosey nelly that has found the tables, and he actually went on the server and opened the database directly... he has been reprimanded for this, and everyone was made very aware that the database itself is not for their use EVER.

I tried to eliminate the upper right controls, but to my dismay, when I used a cmd button to minimize the form, the user was not able to bring it back, so I had to leave those on the screen because the user wants to be able to minimize the data base when not actively using it, and the general consensus was to leave the database open/available for the whole shift, rather than open it every time they needed to enter something.

I have a script on my system that runs a backup of the database every hour, since we have it residing on a san server, and have already experienced the "reason for having a san" fallacy... my database in its entirety just up and vanished one night, thankfully I was in it just as it happened and i was able to contact my server admin immediately and he was able to recover it, though we lost 6 hours worth of data, since his back up only runs every 8 hours. we are a 24x7 operation...

I too try to follow the same guidelines you posted, these came about, fortunately when i learned how to design in Access, eon's ago... in school. That was part of my Office training when Windows 95 was still around... over the years, as MS has made changes to the product itself, I was able to continue manipulating things to my personal whim, until 2013 came out... now I am finding the basic things that made Access a great "small" customizable database have abruptly become extinct.

Anyway... the code you posted previously works great, except that windows aero peek allows you to bring it back.. useless but back none the less... so I will just let my crew know, not to click the aero peek unless they want to restart the database.

I greatly appreciate your assistance!

[sooli]

@ Stevan Bias - I actually have something like your code for my admin functions. =) I am using it for subforms that only the admin can get to, and he loves it.

I do have the X on the switch set to close and compact the database, on all other forms the X takes the user back to the switch, as people are creatures of habit and love that red X, but hate to have to keep re-opening the database... lol

[twinnyfo]

sooli,

I use Access 2010 at work, and did some research and found nothing about 2013 that says you can't create .accde files. Are you perhaps looking in the wrong places?

In 2010, go to File, Save & Publish, Make ACCDE. 2013 should have a similar enough interface that it should be there, unless you have some form of limited version of Access 2013....

[sooli]

I tried to save as accde and ran into issues... i'll try to work them out, but in the meantime...

I still need a work around for using the icon in the task bar to bring the database back on the screen when it is minimized... it brings the application window back too. Boss is now wanting to eliminate the possibility of anyone trying to access the tables and making their own updates. I have the database itself password protected, so if a user attempts to open the mdb file, it prompts for password and if you get it wrong 3 times, the application just closes... I used a form inside the database to do this... was quick and simple way - without affecting the users ability to still update tables using the accdb file.

Trying to encrypt a sample now... to test that out... but fear that will require a password for the users to enter... and he doesn't want that. (we have too many passwords to remember as it is...)

Currently I have the properties set so navigation and menus are disabled, which for most of my users is sufficient. However... the shift button over-rides this...

I was thinking maybe I could Hide the list of tables? this way if someone were to gain access to the navigation field, they wouldn't be able to see them? but I wasn't sure what this would do to usability? Will the tables still be linked?

I tried it earlier today, bringing them back was a little tricky cause I didn't know how... I had done it in separate groups... so when i tried to bring them all back at once... I couldn't... there wasn't even an option... imagine my panic! lol.

If I hide them, will it stay hidden when the user copies the front end to the desktop - and will they stay linked? I am brain storming... so sorry if this seems to be something I should be able to test on my own... i cannot exactly use my users as guinea pig...

[jforbes]

I think the root of the problem here has to do with storing sensitive information in a place where people that should not have permission can get to it. This really isn't so much an MS-Access problem that you are running into, but a Permission/Security issue. Access wasn't really created to address permissions... well it dabbled in it for a while early on and then backed off.

There are a few common ways to address permissions/security when it comes to data, there are more, but I'm only gonna touch on three:

• File System permissions is a very effective method by keeping sensitive information on a FileShare and then either allowing or taking away permissions based on the users Windows login. It is a much better way at securing data than attempting to lock down MS-Access because the permission are managed and enforced by a Server on the Network vs embedding security in a file.
• Encryption is handy and sometimes the best way depending on the applications needs, but I really wouldn't think this would be an option for you as it tends to take a considerable amount of development and overhead when running.
• Network Security can be a great way to lockdown data as that is one of its primary functions. Doing this would take either a custom application or use of an application that provides this for you. One application that is often used for this is MS-SQL Server.

If you can use a SQL Server, I would recommend it as there are a lot of benefits in addition to taking care of the problem you are running into for this post. You can setup the authentication based on the Logged in Windows User so that only people that can login to you network can access data as well as you can give and remove permissions on a user by user basis.

The other option, if you can't talk your Boss into a SQL Server, is to split your backend database based on group roles. You don't have to have only one backend database. You can split it by job function and place data specific for a certain job function into it's own FileShare on your network. Then control users permission on the FileShare. This way Jimmy from out in the shop can enter whatever he needs to enter, but can't see all the interesting comments Mary in HR is entering about him into the same system. SQL Sever would be better, but if your Boss has short arms and deep pockets, this approach may work for you.