Getting Started (1 Viewer)

[Wet_Blanket]

Been awhile since I have posted on here - but I am going to need some help. I've recently started with a new firm that has ZERO employees with any Access experience. I've recently introduced some process improvements that can be done via Access, and got those in charge all riled up. So now I need to design something, but not sure how to accomplish what I want because I am dealing with new challenges.

What I want to do is develop a database that a number of departments can work from.

Here is how I would like it to work: New Accounts opens an account via Access. Completes what they need to do, and it pops up on the Next Department's table for processing. They accomplish their goals, submit and it pops up at the next department.

In the past, I could always get away with having one database that one or two workers would work off of - but I have never developed anything on Access that needs to be used by multiple departments.

My question is, where do I start or how do I even structure this? Would it be a main database on a server, and have satalite databases for each dept sourcing it?

Any advice would help.

 

[Scooterbug]

The first thing you need to do is to plot out the table structures. The foundation of a good db is a good table structure.

As for it being used by several different departments, not a problem. You should have a backend to store the tables. You then create a front end that each user will have on their desktop. The FE will contain all the forms, queries and reports. Tables will be linked to the backend. This setup allows for multiple users to be in the same database without having record locking issues as well as eliminated the biggest cause of database corruption.

 

[Wet_Blanket]

Thank you very much! I have never had to do a FE/BE sort of setup, but this will get me started on the right foot. I'm going to be meeting with all of the departments to determine exactly what they want (if they know that), and lay out the tables.

 

[Scooterbug]

Thank you very much! I have never had to do a FE/BE sort of setup, but this will get me started on the right foot. I'm going to be meeting with all of the departments to determine exactly what they want (if they know that), and lay out the tables.

If the departments utilize forms and such on paper, make you ask them to bring it. The paperwork is a great way to find out ALL the data that they are looking to save. Nothing like getting your tables done and a few forms only to have someone ask you "Hey, where is the spot for their best friends, mothers Maiden Name?????"

As for the FE/BE...it's always a good idea, even with a few users, to use that setup for every database.

 

[boblarson]

As for the FE/BE...it's always a good idea, even with a few users, to use that setup for every database.

I'll even go so far as to say, even with ONE user. That way you don't have to wait for them to get out to modify the frontend stuff. And, you don't lose all of the data should the frontend go corrupt.

 

[AstroDonut]

Also look at the Tools-Startup dialog box too, you can hide menus and other stuff to stop further tampering.

And as tempting as it gets, try to get the structure and data handling done before you set any forms up, you can spend hours designing forms and arranging controls only to have to do them again (well, I did!! lol)

if you uncheck 'Display Database Window' press the shift key when opening your database if you want to change anything

 

[dcb]

You are bringing in a new process as the new guy....
Spend time discussiong the req results with the bosses - fine
Spend LOTS of time discussing the requirements with the real users (often the lowest in the structure) If you get these people on your side - they will take great pride in helping you.
I have done a few of these "in office" apps and the user perseption of the product is everything

Watch the end users - if you are helping someone and they try to fill out a then c then b - dont be too quick to correct them.... often when this happens its because you have missed something in the way they work.
The sign of a great app is when a user sits behind it for the first time and it makes sense to them (not to you)

EVERY USER IS YOUR CLIENT - treat them as such

More often than not silly office politics can kill a great idea!

 

[dcb]

On a more technical level -
I swear by timestamping and logging the creating and sometimes updating user. Can save you heaps of time in tracing faults.

As mentioned below by others - Scoping is everything

Scope:
1) flow (how the user needs it to work)
2) Inputs (where the data comes into the flow)
3) outputs (reports ~ xls etc)
4) tables (how it really works)
5) forms (what each should show)
6) pick up the laptop

 

[Wet_Blanket]

I need to learn FE/BE - thanks to all for the great help. I am excited at this new company because I can design everything the way it should be, unstead of suffering through terrible databases at the previous firm.

 

[boblarson]

I need to learn FE/BE - thanks to all for the great help. I am excited at this new company because I can design everything the way it should be, unstead of suffering through terrible databases at the previous firm.

This might be a good reference for you.

 

[gemma-the-husky]

when yuo say yuo got the guys riled up - do you mean angry, or enthusiastic

either way, you need to deliver now!

 

[Wet_Blanket]

when yuo say yuo got the guys riled up - do you mean angry, or enthusiastic

either way, you need to deliver now!

I would say mostly enthusiastic with a sprinkling of some "resistance to change" types.

Fortunately, this isn't anywhere near my main job function or a firm priority - so I get to set my own timeline.

 

[gemma-the-husky]

i didnt mean instantly - i just meant that whether you had them interested with enthusiasm, or they were still doubtful about the ability to deliver results, you now need to be able to show them some concrete results.

 

[boblarson]

...you now need to be able to show them some concrete results.

Are you sure it can't be asphalt results instead of concrete?