I usually use Excel, and through creative formulas and macros have been able to get myself in some pretty deep trouble!! 
I just finished a one-semester class in Access 2007, and did very well. I now know just enough to get myself into even more trouble!
Actually, I did learn enough to understand that I need to ask a lot of questions about setting up a project before I ever even start it. And this may well be too complicated for me to build. But I'd like to see how much I can grasp.
I deal with engineering reports. An "event" occurs, and we write a report. We've got about 35 people writing reports across about 150 projects. At the moment, we're tracking (not writing, just keeping track of) all these reports using Excel workbooks, at least one workbook per project.
This task screams for a database. I'm wondering how to break down the table structure, and deal with a few "gotchas".
For each report, we track the following:
Project number
Project item involved in the event
Event description
Event date and time
Event category
Who's writing the report
Report number
Deadline for completion
(date depends on event category)
Does this report need ammending with more info?
Who's reviewing the report
Deadline for review
(date depends on event category)
Date submitted for review
Date review began
Date submitted for acceptance
Deadline for acceptance
(date depends on event category)
Date accepted
One of the "gotchas" is that for every event, there are parameter numbers. Could be cycles, pressures, hours, miles, whatever. These parameters vary widely across the different project items. So each project item has to have its own parameter table. Could be two, could be 30 columns. But that unique table has to show for only the asscociated item, and has to be adjustable should the engineers decide to throw another meter on it!!
Another "gotcha" is that this must be implemented across the corporate intranet with the tables on an accessible server somewhere and the forms available to maybe 200-300 people with at least three different levels of general access, and a couple of "special" modes for the reviewers and the Boss.
We do periodic reviews to see how people are meeting deadlines. At the moment, the reviewers need to pull in a dozen workbooks and run a program to cull out the one person under review. We also need to generate an overall timeliness report across a section of projects. This also requires a review of up to 100 workbooks. I'm thinking these are much better done with queries.
*whew*!! It's 'way above my place in the food chain at the moment. But I'd love to learn how to do this.
Any thoughts?
Ed
I just finished a one-semester class in Access 2007, and did very well. I now know just enough to get myself into even more trouble!
Actually, I did learn enough to understand that I need to ask a lot of questions about setting up a project before I ever even start it. And this may well be too complicated for me to build. But I'd like to see how much I can grasp.
I deal with engineering reports. An "event" occurs, and we write a report. We've got about 35 people writing reports across about 150 projects. At the moment, we're tracking (not writing, just keeping track of) all these reports using Excel workbooks, at least one workbook per project.
This task screams for a database. I'm wondering how to break down the table structure, and deal with a few "gotchas".
For each report, we track the following:
Project number
Project item involved in the event
Event description
Event date and time
Event category
Who's writing the report
Report number
Deadline for completion
(date depends on event category)
Does this report need ammending with more info?
Who's reviewing the report
Deadline for review
(date depends on event category)
Date submitted for review
Date review began
Date submitted for acceptance
Deadline for acceptance
(date depends on event category)
Date accepted
One of the "gotchas" is that for every event, there are parameter numbers. Could be cycles, pressures, hours, miles, whatever. These parameters vary widely across the different project items. So each project item has to have its own parameter table. Could be two, could be 30 columns. But that unique table has to show for only the asscociated item, and has to be adjustable should the engineers decide to throw another meter on it!!
Another "gotcha" is that this must be implemented across the corporate intranet with the tables on an accessible server somewhere and the forms available to maybe 200-300 people with at least three different levels of general access, and a couple of "special" modes for the reviewers and the Boss.
We do periodic reviews to see how people are meeting deadlines. At the moment, the reviewers need to pull in a dozen workbooks and run a program to cull out the one person under review. We also need to generate an overall timeliness report across a section of projects. This also requires a review of up to 100 workbooks. I'm thinking these are much better done with queries.
*whew*!! It's 'way above my place in the food chain at the moment. But I'd love to learn how to do this.
Any thoughts?
Ed
></o
