Call Management Database Access 2007

Hello Everyone,

I have spent time online doing training and have just finished Oreilly's
Missing Manual for Access 2007. While I am better now than when I started I
am still stumped on what I think should be a very simple DB.

I am an account manager for an insurane company. Basically a travelling
salesperson for all intents and purposes. I need a database that I can input
all my daily activity into and then run reports that pull out the important
bits of that activity.

These are what I think my tables would (titles only, detail if needed):

Customers
(My list of customers)

Incident Report
(every time there is an issue with one of my companies policies)

Supplies
(I drop off insurance certificates etc)

Training
(we provide training to retailers)

Sales Reports
(we provide customers with reports so they know how their doing)

I need to run a weekly report with bits and pieces from all these above
areas. I have attempted to design this DB several times but I can never ever
get the queries I want. I think it is because I always design them with the 1
single common thread (customers).

Any help would be greatly appreciated!

To get really good use of Access' relationally oriented features/functions,
your data will need to be well-normalized. If "relational" and "normalized"
aren't familiar, plan to spend some time working your way up that learning
curve.

The tables you'll want to use may not (intuitively) be the same as your
daily activities.

For example, you describe "XXXX reports" as part of what you do. In Access,
a "report" is a printed set of data. You wouldn't need to keep the reports,
per se, but the underlying data.

Try this -- take paper and pencil and write down the "things" about which
you need to keep information/data. It sounds like "customers" is one of
those. When you have those categories, then jot down the specific pieces of
data you need to keep, under the relevant categories (e.g., FirstName fits
under Customer, but not under Incident). Then jot down lines between the
categories... for example, can you have one Customer with multiple
Incidents? If so, that's a one-to-many relationship (we're back to
"relational" again).

When you have that done (the "entities" and "relationships"), fire Access
back up and use the entities to design the structure of your tables.

Good luck!

--
Regards

Jeff Boyce
www.InformationFutures.net

Microsoft Office/Access MVP
http://mvp.support.microsoft.com/

Microsoft IT Academy Program Mentor
http://microsoftitacademy.com/

"JBrown" wrote in message
...
Hello Everyone,

I have spent time online doing training and have just finished Oreilly's
Missing Manual for Access 2007. While I am better now than when I started
I
am still stumped on what I think should be a very simple DB.

I am an account manager for an insurane company. Basically a travelling
salesperson for all intents and purposes. I need a database that I can
input
all my daily activity into and then run reports that pull out the
important
bits of that activity.

These are what I think my tables would (titles only, detail if needed):

Customers
(My list of customers)

Incident Report
(every time there is an issue with one of my companies policies)

Supplies
(I drop off insurance certificates etc)

Training
(we provide training to retailers)

Sales Reports
(we provide customers with reports so they know how their doing)

I need to run a weekly report with bits and pieces from all these above
areas. I have attempted to design this DB several times but I can never
ever
get the queries I want. I think it is because I always design them with
the 1
single common thread (customers).

Any help would be greatly appreciated!

Hello Mr. Brown,

I provide help with Access applications for a very reasonable fee. I could
build this database for you for a modest fee. If you want my help, contact
me at .

Steve


"JBrown" wrote in message
...
Hello Everyone,

I have spent time online doing training and have just finished Oreilly's
Missing Manual for Access 2007. While I am better now than when I started
I
am still stumped on what I think should be a very simple DB.

I am an account manager for an insurane company. Basically a travelling
salesperson for all intents and purposes. I need a database that I can
input
all my daily activity into and then run reports that pull out the
important
bits of that activity.

These are what I think my tables would (titles only, detail if needed):

Customers
(My list of customers)

Incident Report
(every time there is an issue with one of my companies policies)

Supplies
(I drop off insurance certificates etc)

Training
(we provide training to retailers)

Sales Reports
(we provide customers with reports so they know how their doing)

I need to run a weekly report with bits and pieces from all these above
areas. I have attempted to design this DB several times but I can never
ever
get the queries I want. I think it is because I always design them with
the 1
single common thread (customers).

Any help would be greatly appreciated!

The newsgroups provide free assistance. Your solicitation is contrary to
the posted newsgroup etiquette.

Regards

Jeff Boyce
Microsoft Office/Access MVP


"Steve" wrote in message
m...
Hello Mr. Brown,

I provide help with Access applications for a very reasonable fee. I could
build this database for you for a modest fee. If you want my help, contact
me at .

Steve


"JBrown" wrote in message
...
Hello Everyone,

I have spent time online doing training and have just finished Oreilly's
Missing Manual for Access 2007. While I am better now than when I started
I
am still stumped on what I think should be a very simple DB.

I am an account manager for an insurane company. Basically a travelling
salesperson for all intents and purposes. I need a database that I can
input
all my daily activity into and then run reports that pull out the
important
bits of that activity.

These are what I think my tables would (titles only, detail if needed):

Customers
(My list of customers)

Incident Report
(every time there is an issue with one of my companies policies)

Supplies
(I drop off insurance certificates etc)

Training
(we provide training to retailers)

Sales Reports
(we provide customers with reports so they know how their doing)

I need to run a weekly report with bits and pieces from all these above
areas. I have attempted to design this DB several times but I can never
ever
get the queries I want. I think it is because I always design them with
the 1
single common thread (customers).

Any help would be greatly appreciated!

"Steve" wrote in message
m...
Hello Mr. Brown,

I provide help with Access applications for a very reasonable fee. I could
build this database for you for a modest fee. If you want my help, contact
me at .

Steve


These newsgroups are provided by Microsoft for FREE peer to peer support.
Stevie is a known troll who has been harrassing posters for years offering
questionable solutions an unreasonable rates. There are many excellecnt
Access developers who gladly help for free. Stevie is not one of them. If he
was any good, his past victims (customers) would be giving him enough work
that he would not need to grovel fro scraps in a free support newsgroup.

John.. Visio MVP

JBrown,

There are some FREE Access 2007 databases available from Microsoft that ight
assist you, such as...

http://office.microsoft.com/en-us/te...428241033.aspx

or the Call database...

http://office.microsoft.com/en-us/te...CT101428241033


--
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II
"JBrown" wrote in message
...
Hello Everyone,

I have spent time online doing training and have just finished Oreilly's
Missing Manual for Access 2007. While I am better now than when I started
I
am still stumped on what I think should be a very simple DB.

I am an account manager for an insurane company. Basically a travelling
salesperson for all intents and purposes. I need a database that I can
input
all my daily activity into and then run reports that pull out the
important
bits of that activity.

These are what I think my tables would (titles only, detail if needed):

Customers
(My list of customers)

Incident Report
(every time there is an issue with one of my companies policies)

Supplies
(I drop off insurance certificates etc)

Training
(we provide training to retailers)

Sales Reports
(we provide customers with reports so they know how their doing)

I need to run a weekly report with bits and pieces from all these above
areas. I have attempted to design this DB several times but I can never
ever
get the queries I want. I think it is because I always design them with
the 1
single common thread (customers).

Any help would be greatly appreciated!

A few specific notes in addition to Jeff and Gina's great advice....

I've been on both (actually all 3) sides of the fence on that one....done,
used, and had my folks use dbs for that type of thing.

I'm assuming that you want to learn Access and do this yourself.. (there are
lower cost commercially available softwares that do this e.g. "Act!" and
"Goldmine". I found it easier to create these in Access than in trying to
deal with not-very-open "black boxes" such as these.

You didn't mention it, but I assume that you need to track/record multiple
people at a company. Here's my guess at a good foundation for you: (shorten
my long explanatory names)

Make a "Companies" table with fields for all of the basic "one to one" type
info for that company. Also an autonumber PK field "CompanyIDNumber"

Make a "People" table, FK = "CompanyIDNUmber" linked to it's namesake in the
"Companies" table. Include fields for all of the "one-to-one" type info on
people. Make an autonumber PK field "PersonIDNumber"

Most likely it would be best to roll the Incidents/Supplies/Training
entities into a single "Actions" with a field to identify which of those
three things it is. You could easily add a 4th or 5th later. Also a filed
to desigate whether it is "things to do" vs. "things done", and maybe a due
date for "things to do". Decide whether these items will be tied to a person
or to a company, and insert a FK "CompanyIDNumber" or "PersonIDNumber" field
accordingly, and link it to it's namesake. Either way has it's pro's and
con's, I generally choose to link them to companies.

"Reports" would be a way of outputting data, not a table or data.

Sincerely,

Fred

Unless by "reports" you meant recording that you gave them a report in which
case such IS data, and could also be rolled into that "Actions" table.

WOW-

What an amazing forum (trolls aside .

So I think I should provide more information. I am somewhat familiar with
access and do have a working DB at this time.

As per my course I started with pen and paper, drew my relationship and
eventually filled in tables using OneNote. I ran this by a few people in the
company and then started making tables. To be honest I have no idea why it
wasn't working at first - I just kept playing with Join Types and it
eventually worked (with a few strange issues that I can work around - these
issues are no doubt my fault I should mention).

The company I work for is huge. The database I am working on is designed to
do two very specific things: A) Show them what is possible if we get away
from paper and B) Make me look damn good!

So far I have sent out a few screen shots of forms and a screen of a report
and people have been amazed. Imagine being the manager of a large gregraphic
area with many territory managers and the only way you can track what they
are doing is by hand written reports (no standardization) and receipts from
their travels.

I won't go into the advantages of a proper DB - you all understand this
better than I.

Before I go on I am going to see if I can paste graphics into this forum.
I'll be back shortly with better information.

Thanks for everything!

JB

On Tue, 30 Dec 2008 08:43:01 -0800, JBrown
wrote:

Before I go on I am going to see if I can paste graphics into this forum.

Please DON'T! This is a text only forum; NNTP does support graphics
attachments but they are inappropriate and unwelcome here.

If you do need to convey information that simply cannot be put into words (and
most problems here *can* be put into words), put an image up on some webpage
such as a blog or picture-sharing site and post a link here.

And good luck getting your company dragged from the 1950s into the 21st
century... sheesh...
--

John W. Vinson [MVP]