Part of a product family initially introduced by Microrim Inc. in 1981, R:BASE was one of the earliest entries into the PC database marketplace. As the first PC product with a relational database engine, R:BASE achieved technical leadership, but it was u nable to develop a strong market following. With the relatively immature PC infrastructure of the late 1980s, an engine-oriented product was bound to lag behind a programming-oriented product in performance and flexibility. As R:BASE market share decline d, the product languished. Last year, Abacus Software Group (Edmonton, Alberta, Canada) bought Microrim and initiated a series of projects aimed at revitalizing the product, and at giving existing customers a reason to recommit their data and application s to it. These projects culminated in December, when Microrim introduced R:BASE 5.5, which lets R:BASE developers create applications that support standard GUI capabilities and controls, and which run natively in today's leading 32-bit operating systems: Windows NT, Windows 95, and OS/2 Warp 3.0. In an effort to appeal to database developers outside of the R:BASE community, Microrim also shipped R:WEB, a toolkit that facilitates deployment of R:BASE applications on World Wide Web servers.
R:BASE is one of the few PC database products today that supports shared databases and applications executing simultaneously under Windows, DOS, and OS/2 over a LAN. The product provides built-in concurrency controls with automatic multi-user support as well as transaction-processing features. You can embed ANSI-standard SQL statements in R:BASE 4GL programs, enabling users to execute R:BASE and SQL commands interchangeably. ODBC connectivity allows R:BASE applications to connect to external databases a s well as access R:BASE tables from external query and analysis tools.
I began my exploration of R:BASE by creating a typical sales management schema. Using RBDefine, this was a straightforward process. Next, I created a Leads table and began defining columns. The first thing I noticed was that column names can be a maximum of 18 characters, allowing long enough names to be descriptive without getting carried away. Then I selected a data type from the data types drop-down list and noticed that R:BASE supports a wide range of data types, including fixed character, varying c haracter, integer, numeric, real, double, currency, date, time, datetime, binary, varying binary, and long binary. The distinction between the various numeric types is in their precision and in the size of the number line each supports.
RBDefine's column definition work surface provides check boxes for specifying that a column value is required (not null), generated automatically as an incrementing sequence, and the result of a computation. If you check either of the latter two boxes, e ntry boxes appear in the detail panel to let you specify appropriate expressions. You can assign default values to any field whose value is not derived from a sequence or calculation expression. The duplicate column feature provides a very handy way to d efine a series of columns that have common characteristics. This is useful when defining tables that include a series of numeric fields such as YTDSALES1, YTDSALES2, and so on. Of course, I have many tables in non-R:BASE format and am usually able to reu se parts of their structures when building new applications. I discovered that R:BASE will import data in any format, but it appeared to work best when I saved my existing tables in dBASE format, used the R:BASE "Attach dBASE Tables" feature, and copied the attached dBASE table into my R:BASE database. In this manner, I imported sales order and item tables into my R:BASE database and kept the schema of the table intact. From here I was able to start defining constraints and rules.
In addition to primary, unique, and foreign keys, the RBDefine work surface permits you to define indexes that the R:BASE engine will use to find and group records when using an indexed expression in WHERE, ORDER BY, and GROUP BY clauses. An index expres sion can consist of concatenated fields, but not expressions. You can simulate expressions in indexes by defining computed fields to store the results of expressions that you want to include in an index. Each field in the index may be evaluated in ascend ing or descending order. When indexing text columns, you have the option of specifying that the index include only the first n characters of text in the column; if you specify an n that's less than the width of the column, R:BASE hashes the remaining cha racters into a four-byte numeric representation of the text.
All of RBDefine's functionality maps to the R:BASE CREATE SCHEMA, CREATE TABLE, CREATE INDEX, and ALTER TABLE commands, and this makes it much easier to get started defining schema. There are just a few usability problems with the RBDefine New Key/Index definition. First, there is no way to change a key definition after you save it; you have to get it right the first time. Second, when you create a foreign key, R:BASE does not verify that the expression you supplied for the key actually matches a primar y or unique key in the referenced table until you finally save all of your table-definition changes. Finally, while you can assign logical names to indexes, you can't assign names to constraints; rather, R:BASE assigns them numeric identifiers, which mak es referring to them and documenting your system somewhat difficult.
After defining my table's columns, constraints, and indexes, I dove into the rule definition form. Rules map to the CHECK clause in the CREATE TABLE or ALTER TABLE commands. The rule definition work surface simplifies applying rules to enforce minimum or maximum values, ranges of values, required entries, deletion tests, and validation against values in other tables. You can create any rule that can be expressed in a WHERE clause using the many functions built into R:BASE. The Where Builder dialog makes creation of such WHERE clauses relatively painless. (See Figure 2.) R:BASE does not currently support triggers.
In addition to enforcement of constraints and rules, the R:BASE engine offers a robust collection of commands to create both transient and persistent result sets using CREATE VIEW syntax. To start with, R:BASE SELECT supports sub-selects, outer joins, un ions, and aggregates. For less process- and logic-intensive data retrieval, you can use the QUERY command, which is similar to SELECT, but only supports FROM, WHERE, and ORDER BY clauses. Another group of relational commands includes INTERSECT, SUBTRACT, UNION, and JOIN, all of which produce a new table from a pair of input tables, based on the relationship between the tables. INTERSECT, SUBTRACT, and UNION perform automatically, based on the existence of a common column in the two input tables. JOIN al lows the user or application developer to specify the relationship between the tables. R:BASE also provides standard SQL INSERT, DELETE, and UPDATE commands. It also uses the standard SQL GRANT mechanism to control access rights to users of tables and vi ews.
To create a new data-entry form, you start by entering a name and description for the form and selecting the primary table. If you ask R:BASE to create a quick form, you may then select from a list of columns, and R:BASE builds a form with those columns arranged vertically. This is not a great productivity enhancement because R:BASE's data definition engine fails to capture information that would be useful at design time, such as a field's default control type and caption. R:BASE makes the width of all field entry boxes the same, regardless of the width of the bound column, forcing you to make repeated fine adjustments with the mouse.
Quick form creates text boxes for the fields you select, thereby forcing you to delete the text box and create another type of control (combo box, check box, and such) where that type of control is appropriate. It uses the field name for all captions, an d requires you to open the text element's properties window using the right mouse context menu just to change the caption. It's actually easier to place a new text box because R:BASE then automatically opens the properties window.
Creating a new form without using the quick form feature presents you with a blank slate. As with most of the current crop of form designers, you can drop text boxes for entry of column or variable values, command buttons, check boxes, combo boxes, radio buttons, and boxes or lines onto the form. The toolbar is sticky -- it assumes that you are going to drop a series of controls of the selected type. When you drop a control, the form designer presents a modal properties dialog that lets you define the c ontrol's data binding and formatting. You can customize some default characteristics of the form in the form settings dialog. This dialog lets you modify passwords for the form, and specify read-only and when to clear the controls, default font, and colo r formats for column and variable entry fields, text objects, and box objects. The dialog also lets you specify whether the form can be used for editing and entering data, as well as the menus to be used in each case. One subtlety that I appreciated is t he ability to separately specify default text justification for both text regions and fields.
With the form designer active, you can create variables that get scoped to the form for use in calculations that are performed while the form is being processed. R:BASE manages most events via entry and exit procedures (EEPs), which you can assign to fie ld and button objects on the form, and also to entry and exit from a row. There are actually three groups of settings that you can apply to text boxes that are bound to columns and variables. The first group of settings specifies basic data binding and t ext formatting. The second group, a Field Settings dialog (see Figure 3), lets you control entry of new data or modifications to existing values, default values or edit mask, help messages to display, and procedures to execute upon entry into or exit from the field. With the third group of settings, you can create a popup menu to supply the value for a field using the Pop-up Menus dialog box. I suspect this feature is going to be largely ignored in favor of the new support for com bo boxes in the form designer.
I like the way that R:BASE does properties dialogs. Because the property dialogs are not exposing object properties that are accessible through the R:BASE language (which does not purport to be object-based or object-oriented in any way), they don't need to list a myriad of property names with entry fields for their values. Instead, the property dialogs are customized to the type of object that they describe, asking a series of questions whose answers are required to ensure the correct functionality of the object. In addition to the property dialogs, I also found the tab ordering, multiple object alignment, and group resizing tools to be very easy to use.
One useful wrinkle of the form designer is the resolution guidelines dialog, which allows you to specify a target video resolution for the form. This accommodates developers who work at a machine with a higher video resolution than do the end users. On t he downside, R:BASE is just about the only development tool I have tried lately that restricts you to designing only one form at a time. The design surface lacks an edit menu, making it impossible to cut, copy, or paste objects, or undo any changes with which you may not be happy.
Collecting related screens and reports into applications is a simple process. Choosing to create a new application in the object manager window opens the application dialog. After you enter a name and select whether to use pulldown or popup menus, R:BASE presents a character-mode window with a menu editor. You then enter the text of the pads and bars that will make up your menu system. To allow you to define the actions associated with each bar, R:BASE presents a menu item actions dialog. You can assign a sequence of actions to the bar, including entering or editing data with a form, deleting rows from a table, browsing and editing data in a table, performing a selection or inquiry, printing reports or labels, and running an R:BASE command sequence. R: BASE permits a secondary application to run within a main application, which you implement by creating a custom menu command that invokes it.
To set up an R:BASE application to run with R:WEB on a Web server, you copy the application to a directory on the server and set up an HTML menu page that allows users to select a database function to perform. For instance, one form may permit the Web su rfer to register for a contest. The R:BASE application would include a contestant table and a contestant registration form. When the surfer chooses to register for the contest, the Web server sends a request to RWEB.EXE, which converts the contestant for m to HTML and returns it to the Web server for presentation to the browser. When the surfer completes the form and submits his or her entry, the R:WEB-generated form executes RWEBCGI.EXE, which submits the data to the table. rweb.exe contains a full copy of the database engine, which can check any constraints or rules and advise the server of any violations.
All in all, this requires no code outside of that required in the normal course of developing an R:BASE application. Indeed, the R:BASE environment's relatively primitive GUI capabilities lend themselves quite effectively to the Web application model. Th e controls and form capabilities that R:BASE supports map fairly well across operating systems and directly to HTML. It's difficult to design a form in R:BASE that can't be rendered in HTML. R:BASE 5.5 adds some support for MDI applications, but the stru cture of the application and the development environment guide the developer toward full-screen, single-form-at-a-time applications -- just like the ones I see during my Web explorations. Finally, the database engine-centric approach taken by R:BASE mini mizes the amount of validation and transaction-processing code that typically resides in R:BASE forms, again consistent with the Web's thin client, heavy server model.
The Web angle is a real wildcard here. R:BASE has a three- to six-month lead over comparable products that promise to offer a similar type of Internet support. This could make it very attractive for applications that are being developed for Web deploymen t on both Internet and Intranet networks. With R:BASE, Microrim can make a very strong pitch to organizations (particularly those running IBM mainframe applications) that need to redeploy character-mode applications in a GUI environment. Its lack of obje cts and tight integration with the Windows environment makes it an extremely easy-to-use development tool for traditional developers who lack RDBMS experience. Together with existing R:BASE 5.1 users, who should find the upgrade compelling, this group re presents the best opportunity for Microrim to expand its user base.
* Microrim Inc., 15395 SE 30th Place, Bellevue, WA 98007; 800-628-6990 or fax 206-649-2785; http://www.microrim.com.
