Sum or DSum to get a total?

[That Crazy Hockey Dood]

Good Morning..

I have an issue with a query which I mistakingly thought would be easy to
design. I took a monthly log that was in Excel and created an Access DB for
this. There are several different forms that write to their own table.
There are 29 different containers in just one of the tables.

At the end of each month I have to provide information to my boss about what
we did that month. My thought was to have a simle form that ran a query
based upon the contents of a boxes that defined month and year. I would
manually input one final figure that we get from our accounting group and
then run my calculation on this new form that I would write the totals back
to a brand new table.

In Excel this was easy to do but I am so lost in Access that it isn't funny.
Does anyone have any suggestions?

Thanks,
Jim

 

[Jeff Boyce]

Access is not a spreadsheet. (write this on the blackboard 100 times...<g>)

If you are already able to do the calculations in Excel, what were you
hoping Access would do that you can't already do in Excel?

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[That Crazy Hockey Dood]

Jeff..

Thanks for the bit of humor. I needed it as I have been struggling again
this AM with this problem.

While a spreadsheet is nice the usage of a DB provides versatility to gather
the data in one location and report on it any way you want. I want the nice
neat feel of the form opposed to the tabular sheets I had to create in Excel.
The continued maintenance on things that change from month to month was more
of a hassle then it was worth.

Maybe I am living in a fantasy world at this point with this project.
Unfortunately, I am not on an island and I don't see Tattoo or Mr. Roarke
(RIP Ricardo Montalban). There must be something I can do to resolve this
issue.

Thanks,
Jim

 

[Jeff Boyce]

Given that I use Access in daily life, and post here in the Access-related
newsgroups, I tend to be a bit biased.

I suspect that you can use Access to help, but I use the term "you"
guardedly.

When folks are just starting out developing an Access application, I suggest
that they have three learning curves they'll need to get past:
1. normalization and relational database design (repeat after me "Access
is NOT a spreadsheet!") - the "what"
2. Access' tricks and tips (the "how to")
3. Graphical user interface design ("what if you created an app and
nobody used it...?")
Oh yes, one more ... the process of application development.

If you feel a bit shy on any of these, plan on spending the time and
resources to come up to speed. Otherwise, you'll frustrate yourself (and
Access).

If this hasn't frightened you off yet, feel free to post back specific
questions, describing what you've tried already.

Note: start with step 1 -- if "relational" and "normalization" are not
familiar terms, brush up on them before trying to get Access to do
something.

JOPO (just one person's opinion)

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[BruceM]

To add to what Jeff wrote, this is a good starting place toward understand
how it works:
http://allenbrowne.com/casu-22.html

There are other tips and links here (links are in their own link toward the
bottom right part of the page):
http://allenbrowne.com/tips.html

This is another good resource:
http://www.mvps.org/access/

There are many fine sites out there. These links contain other links to
those sites, but this should be enough to get you started.

 

[That Crazy Hockey Dood]

Bruce & Jeff..

I thank you for your time and assistance. Believe it or not, I do have some
experience in Access as I took a FoxPro application my department was using
and turned it into an Access application last year. However, I have stepped
away from Access for a few months and lost a lot of knowlege that I once had
fresh in my mind.

I will go through the sites Bruce posted. I have a "theory" background
which helps at times and hurts at others. Thanks for your help and I will
hope to post examples of my issues soon.

Thanks,
Jim