MS Access Issue Tracker

[probiok]

I'm about halfway through developing a new issue management system and it's breaking down. I have no experience in MS Access but the person before me declared it was the best practice and therefore I started in it. My general setup is as follows...

I have a series of audits, 'Audit 1', 'Audit 2', 'Audit 3', which all contain a number of internal characteristics (auditor, date, location, etc). I have created a table for these audits called AUDIT.

Next I have a series of issues that arise from each audit. 'Audit 1' has 'Issue 1', 'Issue 2', and 'Issue 3'. All these issues come from the same audit but also carry internal characteristics such as the severity of the issue, the response to the issue, etc. Therefore I have another table called ISSUES.

I created a form for the AUDIT table, and a subform for the ISSUE table and then created a relationship between the audit names. That means in my ISSUE table I have a column called Audit and say if Audit 1 had 30 issues the first 30 issues would all have a value of Audit 1 there... hopefully you're still following and I'm making a little sense. That way my subform populates all the issues based on what the main form audit is.

Where this is breaking down is I cannot create reports to produce a succinct PDF that ties the individual issues to the corresponding Audits.

So finally to my questions:

1) Is MS Access actually a method worth continuing to pursue for an issue management system?

2) Is my initial setup worth maintaining and continuing? Any input? Should I scrap it and start from scratch under a different best practice?

3) Kind of related to 2, is there any way I could have set this up better? I have a sinking feeling that if I just created a better relationship this would be much more streamlined.

Thanks!

[ranman256]

Access it he the BEST utility for this.
Tho I'm not sure on your table design, but you need:
AuditType,LogDate,Issue, Note

[orange]

I suggest you drop back to some analysis and leave adjusting the current approach until you better understand the requirement.
Quite often beginning developers jump head first into Access(or other DBMS) hoping the software will "solve" the problem.
That doesn't happen. Software does what you tell it.

Step back and get a clear statement of the business and the requirement that this or another database is expected to support.
What is the subject matter? What are the major things involved? How are the things related to each other?

If you do not have any database experience, you might want to work through 1 or 2 of these tutorials form RogersAccessLibrary to experience the design of a database. What you learn can be applied to any database.

Class Info system
Widgets


You have to work through the tutorials, but you will learn.

Good luck.