Deploying my new db

[Chillendw]

So (I think) I finally finished a db I was working on during my internship.

First, thank you to this site (and it's "sister-site") as well as those who have directly answered my noob questions. Appreciate the help.

Secondly, I was wondering how I would go about making it... "user-friendly?" Basically, it doesn't show the objects (tables, forms, etc). Only the pages/tabs and popups forms that I have set.

Also, please mention any other tips you may have, that I I'm (obviously) not aware of.

Lastly, I plan on putting it on 2-5 computers on the same network. From what I've read, splitting the db is probably my best option. Any tips on this as well?

Thank you in advance.

 

[The_Doc_Man]

Remember that "user friendly" doesn't always include showing folks too much. It invites them to play where they shouldn't.

Having said that, I would advise that user-friendliness requires you to determine what users will want to do most often and make that process robust. Make command buttons to trigger the start of their most common tasks. Minimize the questions they have to answer. Sometimes users like a little extra help so look into the ToolTips (mouse-over a control and text pops up) feature. Make the input boxes or selectors have high contrast and an easy-to-read fonts.

Behind the scenes, remember that the less they see, the less temptation they will have and the less confusion they will experience. Trap handlers that (where possible) silently fix things or that give informative messages are always good.

On a form, "busy" might be efficient but it won't necessarily be pretty. With modern displays getting bigger, don't shy away from larger fonts. Look towards uniformity of "Look and Feel" for an entire application by making the backgrounds of the various forms all the same color (or, if there is a corporate color scheme for departments, use it.)

When you DO have to give a user a tweak (programmatically), be sure that the explanation is clear and minimally tech-oriented.

 

[Frothingslosh]

Rules of thumb:

• Anything you leave them access to, they WILL go into.
• Anything that can be broken WILL be broken.
• Anything that can be entered incorrectly WILL be entered incorrectly.
• Your users WILL, at some point, do something you didn't think possible.

At the very least, you should create an executable file for your front end ('Convert to ACCDE') and distribute that to your uses. Before you generate it, I would also strongly recommend turning off 'Show Nav Pane', 'Use Access Special Keys', and Allow Full Menus'. That is basically the absolute minimum level of security you should set.

This does, of course, mean that you will need to create controls (mostly buttons) to handle any navigation users wish to use.

Also, as Doc mentioned, error handling should be used wherever possible.

 

[Chillendw]

Thanks for the replies.

Remember that "user friendly" doesn't always include showing folks too much. It invites them to play where they shouldn't.

Having said that, I would advise that user-friendliness requires you to determine what users will want to do most often and make that process robust. Make command buttons to trigger the start of their most common tasks. Minimize the questions they have to answer. Sometimes users like a little extra help so look into the ToolTips (mouse-over a control and text pops up) feature. Make the input boxes or selectors have high contrast and an easy-to-read fonts.

I have a forms page setup as the main page; kind of like a switchboard for them to pick what they want to do.

Rules of thumb:

• Anything you leave them access to, they WILL go into.
• Anything that can be broken WILL be broken.
• Anything that can be entered incorrectly WILL be entered incorrectly.
• Your users WILL, at some point, do something you didn't think possible.

I can believe it.

At the very least, you should create an executable file for your front end ('Convert to ACCDE') and distribute that to your uses. Before you generate it, I would also strongly recommend turning off 'Show Nav Pane', 'Use Access Special Keys', and Allow Full Menus'. That is basically the absolute minimum level of security you should set.

Just so I get this right;

• Disable 'Show Nav Pane'
• Disable 'Use Access Special Keys'
• Disable 'Allow Full Menus'
• Then convert to ACCDE
• Then "split" DB

Like that? I should also have my Main Form as the 'Display Form' correct?

What exactly does saving it as an ACCDE executable file do/help?

Also, as Doc mentioned, error handling should be used wherever possible.

I reckon I'll have to deal with this as it comes up. I tried going through it on my own and didn't see any errors. However... refer to your list of user behavior.

Also, once I distribute it among the 2-5 computers, if I make a change on my own, in the original DB, do I then have to go through the whole process again? I'd assume so, just making sure. But then what about the information they already added?

Thanks again.

 

[Frothingslosh]

You would split the DB before you make the ACCDE.

Also, don't lose the DB version, because that's your master copy. You lose that, you get to either pay someone a crazy amount of money to decompile the ACCDE, or start over from scratch.

There are plenty of ways to distribute your DB across the company. Where I work, we have batch files saved on the network. We send users shortcuts with app logos hung on the front, and the shortcuts run the batch files, which download a fresh copy of the ACCDE to a local folder and then run it.

There are also ways to have a database update itself.

Search here for things like 'Front End Auto-Update' and you should find a bunch of help.

***

An ACCDE is an executable file. That means that users can't see the VBA, much less change it. They can't change the forms, reports, queries, macros, or (preferably linked) tables, either. The *DATA* can still be changed just fine, just not the front end. The other suggestions are basically to keep them from even seeing 'under the hood', as it were.

Also, note that every time you update the ACCDB and are ready to release an updated version, you'll need to create a new ACCDE. It seems like a hassle, but it's really the only way to keep people out of places they shouldn't be, and sooner or later, you WILL run into a would-be hacker, even if all they want to do is write their own queries.

***

As to error trapping, trust me on this. You can check everything you can think of, and people will still find bugs right away. It might be the first week, it might be the first hour, but it WILL happen.

If you don't have error trapping going on, then they will either get dumped into your code with processing stopped (ACCDB) or get dumped to Windows as the app encounters a fatal error (ACCDE). It's much better to at least include code to generate the error number and message and then terminate through the code. In fact, you'll find code snippets around here that actually handle certain errors and allow processing to continue.

But seriously, you know how annoying a CTD is, and I guarantee people will freak out (and you'll look bad) if they get dumped into the code.

 

[CJ_London]

I agree with everything the other posters have said

Also, please mention any other tips you may have, that I I'm (obviously) not aware of.

my tip is. For your next project do this

Secondly, I was wondering how I would go about making it... "user-friendly?" Basically, it doesn't show the objects (tables, forms, etc). Only the pages/tabs and popups forms that I have set.

first

and you will get to this

So (I think) I finally finished a db

much quicker