Help creating database

[steve goodrich]

Using access 97

My boss wants me to build a database to check the things that we do on a
daily/weekly/monthly basis.

I need a check list so we can mark off a job on completion

we have around 30 tasks that need doing on a daily basis, 10 tasks that need
doing on a weekly basis and 7 tasks that need doing on a monthly basis.

We need to see the tasks that are completed, the tasks that are awaiting
completion and a historic list so we can check when these tasks were done.

Also need to "diarise" weekly monthly tasks

Any advise on how to get started would be greatly appreciated.

I am fairly new to access

Regards

Steve Goodrich

 

[Jeff Boyce]

Steve

You posted in a newsgroup dedicated to supporting the use of Microsoft
Access, a relational database.

Your description sounds like a collection of lists ... is there a reason
this wouldn't work in something like Excel?

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[steve goodrich]

We already have it working in Excel, but my boss wants it in a database.
He wants certain parts of it protecting so no one else can see it - I know
how to password protect a form in access so thought I could build a db and
have forms with check boxes on, run queries/reports to see historic data.
etc

My Idea was to have a form that would default to "Today's date" with all the
tasks listed for that day so we could tick the check box on completion. How
it would default to tasks that were weekly/monthly?

It would also be used as an audit trail

Steve

 

[NevilleT]

Hi Steve
What you are being asked to do is not trivial. There are a number of
component.
- Function to give particular users access to particular actions. In effect
a security system.
- Some means of history tracking where you can see if details have been
changed. For example I complete a task today which was due a week ago, and
backdate it, or come back later and change the completion date.
- Sounds like some are recurring tasks so you need a mechanism to replicate
tasks with a new date.
We have recently build some of that functionality for another client and
there were man weeks from an experienced Access developer to get it working
properly. I would suggest you talk to your boss about either getting an
experienced Access Developer to do the job, or find a tool that will do it
for you.

Neville Turbit
www.projectperfect.com.au

 

[Jeff Boyce]

I'll echo Neville's comments...

There are three or four learning curves to overcome in using Access to build
a user-friendly application that ACTUALLY GETS USED!

1) Relational database design & normalization
2) Access tips/tricks
3) Graphical User Interface Design
4) Application Development

If you don't have the time to come up to speed on all 4, you STILL need to
know about them, to help you pick a knowledgeable developer to hire.

Good luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Jeff Boyce]

Send your boss to this newsgroup ... a really smart boss realizes that s/he
specifies "what" needs to be done, and let's folks who know figure out
"how". <G!>

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[NG]

Hi Steve,

before starting to program this, I would look what already exists on the
market. There are a fair amount of programs that deal with task and project
management, ranging from the task manager in Outlook to very sophisticated
dedicated software.
If you're boss insists on doing it in Access, you can do it if you already
have some experience with relational databases (Oracle, SQL server, ...) and
programming (.net, VB, Progress, ...). In this case Access is rather easy to
master, but you'll need a fair amount of programming to come up with a good
application.

 

[BruceM]

Outlook has some pretty good tools for managing this sort of thing.

 

[Fred]

We use Access as a platform for a combined planning and task management
system. (Actually, all of the above integrate into a heirarchy that goes
from strategic planning down to task levels.) It is highly customized to
us....which is why what we have would be worthless to you, but illustrates
that the flexibility, power and openness of an Access platform can provide
advantages.

The gist of the excellent advice that the other respondents have given you
is that doing the described application (especially the special things that
your boss wants) yourself will probably be a sort of 1 year learning curve
(at a typical pace, if you're up for the learning effort) for you, combined
with developing the application over months and refining it over years. If
your boss doesn't want to hear that, then (as the respondents described)
you're either going to have to get some help or use a completed commercial
software....the latter would probably require some adaptations of
expectations.

 

[Jeff Boyce]

.... or find a new boss ... <g!>

Jeff

 

[steve goodrich]

A new boss sounds a great idea! No he's ok really.

We work for a company that has a strict policy on the software that can be
installed on our pcs. It's basically Access, Word, PowerPoint & Excel -
That's it!
I have no programming experience and all the db's I have every built have no
related tables. That said - they all work for us and have served us for many
years with no problems. My job doesn't involve computers as such and
basically I have built the databases we use as a tool to do general office
tasks. There are no external customers dependent on them. If the db I build
goes wrong then it's no big deal, there's always another way to do it. I am
trying to learn Access, but not coming from a technical background I find it
very difficult - The help files for example might just as well be written in
Chinese!!!

That said - I usually find a way of achieving what we need, (If one of you
guys took a look in detail at one of our dbs you wouldn't stop laughing for
a week!! (but they do what we want them to do, may not be efficient, but
they get the job done).

Employing an Access developer to build the dbs is a non starter, I'm sure
that it's not just our company out there that's trying to cut costs at every
opportunity.

He's what I have in mind (Don't laugh)

A separate table for Daily tasks, weekly, monthly, quarterly, yearly. with
the task required and a check box for each.

A form linked to each table so the user can check the relevant box when the
task is complete.

A form (switchboard) with command buttons that will open each form

I could have a password protected form for the boss so he could allocate
adhoc tasks,
Afew queries/Reports could be created as required.

The check boxes on the forms are just for staff to check when a task has
been completed - the same as marking it off on a spreadsheet, checking when
the box was checked or if it has been altered retrospectively is not an
issue.

I am learning at a snails pace but am under no pressure to build an all
singing all dancing db. Time is a real problem. as I say this is not my full
time job, sort of trying to build it as and when I can to help colleagues in
a great friendly office environment.

Any help from anyone would be greatly appreciated

Best regards

Steve Goodrich

 

[Jeff Boyce]

Steve

I'll refer you back to one of my earlier responses.

I urge you to consider the 3-4 learning curves I mentioned. If you feel
like you're near the bottom on any of those, plan on taking the time to
learn your way up that/those curves before expecting to get Access to work
well/easily for you.

There's no harm, no foul in creating something that works. Now you just
need to decide whether the goodies Access offers is worth the pain to come
up to speed. If you have another way to get the job done, one that you
already understand, go for it!

That said, Access is more a power tool than a bookcase. You can learn to
use it safely and properly, and, in the end, build some really nifty
bookcases. Just don't expect to walk up to it and have it be easy to
understand.

Best of luck!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Larry Daugherty]

Hi Steve,

You're not hearing (or heeding) the good advice you have already
received. Believe it or not, we would like you to succeed with your
use of Access to solve your business problems. We will not knowingly
help you shoot yourself and your boss in the foot or feet.

Your last post indicates that you haven't completed your analysis or
possibly don't know what it means or possibly think you know your
prospective application so well that you don't need to express it
before beginning your design. To wit: you have already proposed a
design based on incomplete and incorrect analysis. Proceeding in that
manner will lead to producing yet one more "laughable" application
that will be difficult and expensive to enhance and extend.

By the way, any application that finds some use has a value so don't
worry about past efforts. The problem with so many amateur Excel
based applications is that they are not highly automated and they are
not user friendly at all. They depend on the user being the most
critical part of the "program". The user is expected to know where to
go to replace data, enter new data and to interact in other ways with
what's there. Excel can be used to produce some pretty slick
professional applications (if I do say so myself!). The biggest
single problem people experience in coming to Access from managing
data in Excel is that they believe Access is simply a quirky version
of Excel. 'Taint so! Excel is flat. Access is Relational. Excel
is essentially a calculating platform. Access (en toto) is a
Relational Database Management System (RDBMS). Actually, Access is a
whole bunch of development tools that assume a RDBMS will be a part of
the mix.

In a "good" Access application you will not allow your users to see or
interact with the tables directly. You will provide meaningful forms
for your users to complete their tasks (in other words, all tasks have
to be defined and then you have to provide the forms and means to
complete them. No other tasks will be allowed!). To the extent
possible you analyze the proposed application and create a
specification before any code is written. When the specification is
complete, that becomes the "contract" for the application; all
epiphanies and bright ideas encountered before completion will be
noted for latter address. Deliver the contracted application and get
it signed off. If the will is there, peruse the new ideas with the
client for a new release. I would ask the client to use it and take
not of any more new ideas for inclusion in that second phase.

For a journeyman Access developer your proposed application seems to
be fairly small and relatively uncomplicated. If you and your boss
are ready, willing and able to fully specify the result you want and
the inputs available (with assistance from a developer) the technical
aspects of the whole thing could take a week or less. It could take
as long as a month if people are slow to respond with requested
documentation or to get to the phone. If you're in the least bit of a
hurry that's the way I'd recommend. Insist that the developer
document the code so that you can learn from how your Access
application was built.

Whether you do it yourself of have it done, you'll still want to learn
more about Access. There is a list of resources below that can help
you if you will use them and apply yourself. Start with the things
that seem easiest to learn and go on from there. If you were to
consume all of the items on the whole list you would be an Access guru
of awesome stature.

A couple of newsgroups I always recommend for Access newbies are:

microsoft.public.gettingstarted
microsoft.public.tablesdesign

A list of priceless Access resources I cribbed from the frequent posts
of John Vinson is below

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

Roger Carlson's tutorials, samples and tips:
http://www.rogersaccesslibrary.com/

A free tutorial written by Crystal:
http://allenbrowne.com/casu-22.html

A video how-to series by Crystal:
http://www.YouTube.com/user/LearnAccessByCrystal

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials

HTH

 

[Jeff Boyce]

Larry

Nice summary!

I tend not to require the "explain everything you want before we start"
approach, though, because most folks don't know what they want!

I'll work with a prospective client to identify the 2 or 3 most-critical
aspects of what they're trying to accomplish, and negotiate an agreement to
work for a (limited) time on those. If those aren't possible, or achievable
within our lifetimes, then we're better off knowing that up front than
discovering that six months into the project.

After the first round, the client can walk away with what they have so far,
or engage in another round of identifying the (next) most critical aspects.

Of course, back to my original thought -- at each step, helping the client
identify what s/he's after has to come before any specs!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Fred]

Here's some baby step advice on top of the excellent big picture advice
already given to you byu others.

With regard to your likely level of Access knowledgein the near future, the
more complex user-access cotrol functionality etc. that your boss is
discussing makes it that your question is mixing two things together.

It sort of like saying "my boss is thinking of switching me from a
motorcycle to a car, and, by the way, the reason for the switch is to win
the Indy 500 with the car next week. Do you think I can handle this
switch to a car?

My advice is that a good start would be to tell your boss that under the
multiplle constraints he has given you (you have to build it 100% DIY - no
pre-made software, and no paid help) that the only choice he has is to
seperate the "car switch" from the Indy 500.

In other words, to start by just moving your application to Access, (which
probablyu won't be that tough) and winning the Indy 500 will have to wait
under the constraints that have been placed on you.

 

[steve goodrich]

Thanks guys for all your advice. I know it's a very big learning curve - I'm
learning all the time. I find this ng one of the most useful resources -
keep up the good work, it really is appreciated.

 

[Larry Daugherty]

Thanks Jeff,

I hope it was useful to OP.

Most useful to the neophyte is getting to know about the territory
that he or she doesn't yet know but that they will likely have to
travel in order to get done what they want.

I admire the ambition of everyone who is learning and using Access.
Having learned all of the little I know about the subject by self
directed efforts, I'm in complete empathy. Help files, books,
magazines and other resources all helped. How about Smart Access!! I
also learned a lot by lurking these Access newsgroups to see what
others were posting and seeing if I could understand and resolve their
issues. That was time consuming but useful. Eventually, I started
occasionally responding to posts. When I do respond I usually do so
with an awareness of the hundreds of "lurkers" who aren't a visible
part of the dialogue but who benefit nonetheless. Sometimes I don't
give posters the simple result that they seek but point them instead
to the resources they have available to be able to help themselves.

I'm awed by the succinct responses of John Vinson and Allen Browne in
particular. I don't think they're naturals, I think they worked to
get that way. There are lots of others ...

Your own posts are great examples of common sense reasoning applied to
a complex subject area. Getting people to understand the real issues
they face in getting to a solution they want is even more important
than complete mastery of the technical expertise. You help lots of
people grasp that valuable insight and place Access in its proper
place as a tool for providing solutions rather than as the embodiment
of specific solutions.

Kudos

 

[Jeff Boyce]

Thank you for the kind words, Larry. I, too, am in awe of John & Allen,
among many others.

I decided long ago that my mind doesn't go the same places that theirs do,
and I don't even aspire to be able to do what they do.

I also realized long ago that I 'break things'. Not maliciously, but just
because I tend to ask those sometimes annoying questions that can help
reveal what isn't yet understood.

Some folks just want to know "what button to push" ... and there are many
here who can help them.

I tend to ask "why are you pushing that button?" ... or even "?there's a
button?!"

Regards

Jeff