possible features of a problem-tracking database?

[Jeffrey Tan]

So this whole database I'm working on at work is a problem-tracking database where my colleagues keep track of user & printer problems.

I would like to know if there are any notable features that a problem tracking database must have? I have researched a bit on issue-tracking systems: http://en.wikipedia.org/wiki/Compari...acking_systems but I can't seem to narrow it down to name a few features a problem tracking database must have.

Thanks in advance!

I have two forms: user and printer that basically have the following fields:

• troubleno: autonumber PK
• date opened
• user
• problem category
• opened by
• status (open, closed, canceled)
• closed by
• brief description
• notes (memo)
• subform/report for problem history where there are three columns (user, date, and problem history)

similar one for printer form.

i have a main form that lists the current # of open tickets, closed tickets and the # is a hyperlink that opens up a form containing a listbox, showing the opened tickets and when a user clicks on a specific record, it opens the user problem log form and jumps to that record.

what other features do you think i should include? we can brainstorm and see if the ideas mentioned are already included in my database and if not, ill consider them :)

Thanks a bunch!

[NeoPa]

I would consider two ideas :

1. Unless you are aware of reasons I cannot see, make a single form do both jobs. Certainly also, maintain the printer and user data in the same table. An [Item] field can easily replace the [User] and (presumably) [Printer] fields in the tables. This would involve including something (possibly a flag field) to indicate which type the record pertained to. Just a thought to your maintenance lighter going forward.
2. Unless you intend to garner this from the records of your history table, add a [Date Closed] field. Your [Status] field would then be a simpler [Canceled] flag as the other statuses would be determined by the presence or absence of a value in the [Date Closed] field.

Otherwise my experience of exactly these types of databases is limited.

PS. Good job on the question. Well laid out and considered :-)

[Jeffrey Tan]

@NeoPa
Thanks for the suggestions NeoPa.

I guess my supervisor wanted the database to be easily managed so he split the forms up into user and printer. there's not much tickets regarding printer, so to him it makes things a bit easier. But I like the idea :)

For the Date Closed field, it is already on the form :)
Basically, then the user selects from the status combobox CLOSED, it automatically populates the Date Closed.

[NeoPa]

Jeffrey:
I guess my supervisor wanted the database to be easily managed so he split the forms up into user and printer.

Perhaps they don't appreciate that this choice reflects the opposite of their requirement. Their choice of course, but everyone should at least have the benefit of being informed before they make it. Between ourselves (There's no benefit to anyone passing this on) such choices generally reflect inexperience in database work. It's an approach that, when extended - and we always extend from our existing experience going forward of course - leads to more work and slower development times.

[Rabbit]

I don't know that there are too many things that are absolutely required. Really, the bare minimum is a description of a problem, who the contact person is, and whether or not it was resolved. But there are plenty of good-to-haves.

A few of those are:

• Priority Ranking
• Requested Completion Date
• Work Hours