Special

Introducing the “Welcome to Xojo” Bundle!

New to Xojo and looking for guidance? We've put together a terrific bundle to welcome you! Xojo Bundle

This bundle includes six back issues of the magazine -- all of year 21 in printed book and digital formats -- plus a one-year subscription (beginning with 22.1) so you'll be learning all about Xojo for the next year. It's the perfect way to get started programming with Xojo. And you save as much as $35 over the non-bundle price!

This offer is only available for a limited time as supplies are limited, so hurry today and order this special bundle before the offer goes away!

Article Preview


Buy Now

Issue 6.2

COLUMN

Swatter

A simple bug database

Issue: 6.2 (January/February 2008)
Author: Brad Rhine
Author Bio: Brad Rhine is the developer of Kodiak, a complete student information system written entirely in REALbasic. That's his day job. In his spare time, he writes shareware applications in REALbasic.
Article Description: No description available.
Article Length (in bytes): 9,598
Starting Page Number: 34
Article Number: 6214
Related Link(s): None

Excerpt of article text...

In this issue, we begin a new project. We recently completed iDater, a small program to edit files' creation and modification dates. Today, we begin Swatter, a simple bug database.

Be forewarned: we're not going to get into any REALbasic code in this issue. Instead, we're going to discuss what our program should do and how we should set up the database (so we will look at some SQL code).

Defining The Goal

Since Swatter is significantly more complicated than iDater, the very first thing we need to do is determine our requirements. What does a bug database need to do? Well, first it needs to keep track of our projects and their associated metadata. If you really wanted to keep it simple, you could limit the program to one project, but that's a needless limitation, especially when dealing with an API as easy to use as the REALbasic database API. In addition to our projects, Swatter needs to keep track of bugs and feature requests, which we'll combine and refer to as issues. We need to make sure that each issue is tied to a project. We also need to be able to edit and delete issues requests as necessary. In addition, we should build a way to track our users who report issues. Each user could be related to any number of issues.

If we wanted to get fancy, there are a few more things we could do, but won't for the sake of time and simplicity in this project. One is adding a mechanism to track developers, so that different bugs and feature requests can be routed to different programmers. There are a few other potential additions that I'll mention along the way.

...End of Excerpt. Please purchase the magazine to read the full article.