Approach vs. StarBase - by Christopher B. Wright

atabase applications are murderously difficult programs to learn to use well. Because they can store, sort and display huge quantities of information -- even the simple ones -- they don't always have simple and functional interfaces.

Databases are getting easier to use, however -- probably because they are being bundled into office suites with increasing frequency. They have not reached the level of simplicity that most Word Processors have, but they are at the point where end users can create functional, useful databases without having to learn a programming language.

Overview

Both Lotus Approach and StarDivision's StarBase are functional products, but Approach gets the nod for power and ease-of-use. As of this writing StarBase has very little support in Star Office's skeletal help system -- there are only four entries that I could find -- and unlike most of the rest of the suite, its interface is not terribly intuitive. Approach's interface, on the other hand, is very intuitive -- there are a few hang-ups but for the most part, all tools are either self-explanatory or easy to figure out. Approach also seems to have internet connectivity -- you can publish your database to the world wide web -- but it requires a DB/2 server to do so, which limits its usefulness in that respect. (Approach is not intended by IBM or Lotus to be a commercial database product).

On the other hand, of the two products Approach is the one that is most glaringly a beta product. its performance is sluggish -- on some machines it may not run very well at all -- and there are various widgets and mouse actions that don't seem completely implemented. StarBase, while unwieldy in implementation, functions smoothly and consistently.

The Project

To test both products, I decided on a specific goal before I started working with them. I was going to try and create a database for the Project:ToolBase portion of the Desktop Communications web site (which I maintain when I'm not writing here or working 9 to 5). Project:ToolBase is a listing of available publishing software for OS/2 (including native, DOS, and Win16 programs), with links to reviews where available. It will be expanded in the future to include compatible hardware as well.

At the moment, I simply add information to the web page -- a cumbersome task that will be almost impossible if it grows much more and software versions change. Ideally, I'd like to ultimately have all information in a database that will interface with the web page itself -- so that people can view the page and perform searches, sort by various fields and so forth. I can't do this right now -- I don't have CGI permissions with my current web host -- but I want to set up a database that will keep track of all my information and that can be expanded upon in the future.

So the criteria I used when testing these beta products was: how easy is it to create a database? How flexible is it at entering and displaying the information? How well can it integrate with a web site, and which of these tools would I be able to use right now?

Lotus Approach

Approach is a wonderful database with a lot of quality, easy-to-use features. It has a few performance glitches, however, and it may require too much in the way of system resources for some PCs to handle.

Approach: how easy is it to create a database?

Building a database using Lotus Approach is a marvelously straightforward process. When you open the application, you're given the choice between building a database from scratch or starting from one of the SmartMasters (GIF, 20k) (a SmartMaster is Lotus' version of a template). The SmartMasters didn't cover what I wanted the database to do, so I chose to start from scratch. Then, strangely enough, it asks you to choose a name for your database, and the directory it will reside in. Apparently, Approach creates the file before you even begin building it.

Once you've named and placed your database, the Creating New Database Window (GIF, 12k) opens up where you define all your database fields. Here you not only specify what the name of the fields are, but how long the field is (how many characters it will accept) and what type of field it is. You're given a great deal of flexibility on field types -- you can set it as a text field (all characters are viewed as text, nothing more) or you can set it as a field solely for containing calendar dates or numbers (the numbers field can be further defined to record a number as currency), or as a simple "yes/no" field. You can even declare the field as a "memo" -- which means you can enter an unlimited (for all intents and purposes) amount of text into it. You can declare as many fields as you wish, and each field type has customizable settings (GIF, 22k).

Not all of the field types are as customizable as I would have wished, however. When I was setting up the Project:ToolBase field list, I created a field called "Software_Version" which was intended to display the release level of the software code. I had to configure it as a text field, because it wouldn't recognize the latest release level of the now-defunct Describe word processor as a number: it had too many decimals (5.0.6). Also, some release levels are a combination of numbers and letters (for example, "1.01a").

Some of the field customization features are very nice. I created a text field called "Category" that would classify whether or not a software item was a desktop publishing, graphics design, multimedia authoring, or web creation program. Using the customization features I was able to set it up as a drop down list that would allow you to choose any one of those four categories. I did the same thing for a "Native_OS" field that would allow me to declare it as an OS/2, Windows 3.1 or DOS application.

One thing I didn't think of when I was doing this, however, was that some applications fit in more than one category. StarWriter, for example, can be viewed as fitting in both the desktop publishing and web creation categories, since it has a lot of layout and web design features. Using the drop-down lists, I was only able to choose one category. This was solved by removing the "Category" text field and replacing it with four "yes/no" fields: "DTP", "GD", "MMA", and "WC". In the example of StarWriter, I would be able to set the DTP and WC fields to "yes" and the others to "no".

Once you are finished defining the fields, your next step is to set up the data entry area using the Browse/Design Database window (GIF, 50k). This is not really a required step because you can always enter information in its default table view, but if you plan to enter a lot of information over an extended period of time you may prefer setting up a more logical and easy to use format.

Approach allows you to customize your data entry area by changing fonts, field backgrounds, colors -- almost every aspect of what you're doing. You can even create and apply styles. For example, I created a style called "Field_Title" and applied it to the text over each field to give it a uniform look.

Each part of the data entry area has specific properties that you can customize through their settings tabs. All you need to do is double click on an area for the settings tabs to appear (or you can right click and select the "properties" choice on the task list. There is also a floating palette that gives you the ability to add graphical elements to the data entry area, as well as some form items (radio buttons and check boxes).

Approach: how flexible is it at entering and displaying information?

This is one of the areas where I had some difficulties. Approach doesn't make it easy for you to set the tab order of your fields. When you are entering information into a database, it's pretty standard for you to be able to jump from one field to the next by hitting the tab key. Unfortunately, Approach tends to set the tab order by the order in which the tabs were created, not the order in which they appear in the data entry area. You can choose to take a field out of the tab order (so you won't be able to tab to the field at all -- you must click on it with your mouse instead) but I wasn't able to find a way to rearrange the tab order at all. Even when I went back to the window that controls the field definitions and rearranged them, Approach insisted on using the original order they were created in to determine the tab order.

This made entering the information a little awkward. I was never able to follow the tabs fast enough to just "tab and type" my information into the database, and that slowed things down considerably.

On the other hand, creating a report is a very easy process. You can choose from Approach's pre-generated formats and modify them to suit your purposes, or you can create them from scratch. After deciding what fields from the database you wish to display, you then customize the appearance of the report in much the same way you customize the appearance of the data entry area. These reports are automatically updated as you enter and update information into the database -- but if you add or change fields, you may need to alter the reports accordingly.

Approach: how well can it integrate with a web site?

I was disappointed with the way Approach handles web integration. Based on some of the things I'd heard about it, I was hoping it would be able to create reports that were essentially static html pages with the information I wanted to display. While it might actually be able to do this, it's not as immediately apparent as the rest of the application.

Approach can allow you to interactively display the information on a web server if the web server is running DB/2 -- but this is a very expensive solution to the problem. If anyone knows how to convert an Approach report into static html pages, please let me know.

Approach: how usable is this application right now?

In terms of ease of use, Approach is an excellent program -- it's about as intuitive as a database application can be at this point in time, with the sole exception of its internet connectivity features which are pretty arcane. However, Approach has some glaring bugs: first, drop-down lists have a tendency to be inaccessible by a mouse. You can drop the list down with a mouse, but you can't choose any of the options, nor can you scroll up and down the listing (you must use the up/down keys on your keyboard to scroll and the enter key to select). This is can be a cumbersome and awkward situation, and really needs to be fixed.

Also, Approach is a very slow program that generates quite a swap file. At times there was as much as a seven or eight second delay before a settings tab would appear, or a window would open or close. Take into account that I'm running this application on a Pentium Pro 200 with 160 megs of ram -- on a more 'standard" machine, this application will run even slower. How much slower I don't know, and this problem may very well be fixed in the final release, but as it stands right now it may be unusable on some machines.

Finally, trying to use the help screens locked up my the program instantly. It was possible to call up the OS/2 task list and close the help window (allowing the rest of the program to be used shortly thereafter) but while a help window was open, the entire application was unusable. This made it practically impossible to figure out how to use the web integration abilities of the program -- they might be there, but with no documentation describing how to use them and no practical way of accessing the help information, they may as well not be. A working help system is absolutely critical for any database application -- especially when no manual is present. People who intend to use a database program regularly should make certain they have access to thorough documentation before they attempt to use it to store critical information.

StarDivision StarBase

StarBase is a very stable and reasonably responsive program -- compared to Approach, it runs very smoothly. This isn't surprising, since it's been in beta for close to two years, but what was surprising was that I didn't find it terribly useful. As far as databases go it seems lacking in power, difficult to use and downright confusing to set up. Based on the intelligence and forethought that went into the rest of the suite, I was very disappointed to find that StarBase seemed "tacked on" to Star Office almost as an afterthought.

StarBase: how easy is it to create a database?

Even the method of getting the StarBase components of Star Office to activate isn't immediately obvious. Unlike the rest of the suite, there is no StarBase item on the little "New" button on the Star Desktop, nor is there a StarBase template available in the templates section. To create a database, you must right-click on the Star Desktop and select New>Database from your list of choices. Because this is the only way I've found so far to create a database in Star Office, and because information on it is so scarce in the help files, it's quite possible for people to use this suite and not even realize there is database included with it at all.

Once New>Database is selected, an interactive panel will appear asking you whether you want to create a database from scratch or whether you want to use one of the templates (templates are only available here, you can't select them from the "file>templates" area on the menu). If you choose to use one of its pre-created templates, you are asked to choose whether it's a database for the home or for the office. StarBase gives you a lot more choices in terms of pre-created databases for you to choose from than Approach does, but unless you have only very basic needs you'll probably want to create one from scratch, as I chose to do.

It asked me for information about what the database is named and what kind of database it is (you can choose between a dBase, ODBC or text database). It does not, however, tell you what advantages/disadvantages each format has (and the help button didn't work), so I picked ODBC at random and moved on.

The new database appeared on the Star Desktop (GIF, 10k) as P:TB (the name I'd given it). Double clicking P:TB revealed that it was a folder, with four other folders (GIF, 26k) in it. It wasn't until I messed around a little bit until I learned that I had to open the folder named "Tables" first (so I could create the table that would hold the actual information). The Tables folder isn't placed so that it's intuitively obvious that you use it first -- it was placed last in the list.

Opening the Tables folder revealed -- nothing. It was empty. Once I opened the Tables folder I had to right-click and choose New>Table in order to open up the screen where I actually defined my database fields. This is many, many more steps than Approach used to reach this relatively early stage in database development.

Once I got there, though, it worked pretty much the same way -- you define the name of the fields, you define how many characters the field can contain, and you customize the field type. StarBase doesn't have as many choices as Approach does, however; first, the name of the field is restricted to 10 characters only, and you can only use standard letters and numbers. There were fewer field types, and the fields themselves couldn't be customized as thoroughly (for example, I couldn't figure out how to create a drop-down list like I did for the Category and OS_Type fields in the Access version of the database. A feature that StarBase had that Approach seemed to lack, however, was the ability to define a field as mandatory (it would have to be filled in during a data entry session).

Once I finished defining my fields, I needed to leave the Tables folder and open the Forms folder -- which I found awkward to do efficiently because when I closed the Tables folder, it closed the entire database and I had to reopen P:TB. You can use the navigation buttons on the Star Office desktop to avoid this problem, but if you forget and tick the close button you're out of luck.

You create Data entry forms the same way you create tables -- by right-clicking in the Forms folder and choosing "New>Form". When I did this, I was asked to link to table in the Tables folder, choose what fields I wanted to use, choose a basic format (GIF, 13k), a basic style (GIF, 13k) to work with, and then name the form (GIF, 14k) itself.

The Data entry screen, annoyingly enough, opens in read-only mode -- I couldn't change the way it was laid out until I closed it, right-clicked on it, and selected Edit. After that, however, arranging the layout of your data entry area worked in StarBase pretty much the same way as it does in Approach, though there were less options to "finesse" the user interface.

StarBase: how flexible is it at entering and displaying information?

A significant advantage that StarBase has over Approach is that it's very easy to define and redefine a field's tab order -- simply right-click on the field and enter its position. This can make data entry a lot easier, and can theoretically allow you to enter a lot more information in a lot less time.

On the other hand, StarBase is less flexible than Approach when it comes to generating reports. Generating a report required that I go into yet another folder, right-click and select "New>Report". After that it was pretty straightforward, I selected the fields I wanted displayed, and chose my basic report format -- which came up in a read-only view, forcing me to close the file, right-click on it, and select "edit" again. Unfortunately, I didn't have a whole lot of choices when it comes to arranging the information displayed on the report. While I could change the font and type size that the information was displayed in, the actual positions and sizes of the fields were stubbornly resistant to manipulation. This was awkward because one of the fields was a memo field (it contains a short paragraph description of whatever software is being profiled at the time) and needed to be larger than some of the others.

StarBase: how well can it integrate with a web site?

Because Star Writer has so many browsing and web creation tools, I assumed that StarBase would be able to create static HTML pages based on its reports with little or no problems. As far as I can tell, I was grossly mistaken. I'm qualifying that remark because there isn't enough documentation on the database to determine whether or not the tools exist; if they do, they're obscure enough to resist my searches for them.

StarBase: how usable is this application right now?

StarBase performs consistently enough to use it for simple database needs. Because you can define the tab order of the database fields yourself, you can set it up as a simple database that stores a lot of information. However, due to the simplicity of the report generator you might find it unsuitable for even moderately complex tasks.

One of the problems StarBase has is that while it may have tools it appears to lack, there is no way to find out. The help menus are disabled in the application, and there are only four items concerning StarBase that I have found in the help overview located on the Star Desktop. Help screens and manuals are absolutely essential components of an application -- especially a database -- and unless it is amazingly simple to use, a database program that doesn't have them is effectively useless.

StarBase does not meet the expectations created by the quality and feature set of the other components in the Star Office suite, and this is disappointing. Star Office can survive quite well without StarBase, but people who are specifically looking for a suite with an integrated database will probably not be impressed with its offerings.

Conclusion

I liked using Approach much more than I liked using StarBase -- the interface was simpler, yet you had more control over what it could do. StarBase felt unwieldy and awkward to use. On the other hand, StarBase felt more like a finished product.

There are a few situations where StarBase would actually be a better choice for someone to use. If they require nothing more than a simple database, have no elaborate layout requirements for their reports, and need something that they can sit in front of and key in data all day, StarBase will work just fine. Its ability to easily define the tab order may even make it better than Approach, where if you're not careful you'll be jumping all over your data entry screen when you enter your information.

For the most part, however, Approach is simply a better designed database application. It's slower and it feels as if a piece or two is missing, but the ease of use and logical layout, in my opinion, compensates for this above and beyond my expectations.

Unfortunately, however, neither of the database applications seems to be able to do what I want it to do -- generate a report that can be viewed as a static HTML page. While it's entirely possible that the functionality exists in both products, the tendency for the Approach help system to lock up the program, and the lack of StarBase information in the Star Office product makes it practically impossible to figure out a) if the functionality exists, and b) how it works.

Christopher B. Wright is a technical writer in the Richmond, VA area, and has been using OS/2 Warp since January 95. He is also a member of Team OS/2.

Copyright © 1998 - Falcon Networking

ISSN 1203-5696