Inside Out II

An industrial strength database engine

By Kirk Chase, MacTech Magazine Regular Contributing Author

Introduction

Inside Out II (referred to hereafter as “ISO”) is an industrial strength database engine for the Macintosh. [This review is on version 2.1.1. Version 2.2 will be released by the time you read this. - Ed.] ISO has some unique features that make it desirable for developers.

• It’s fast.

• It’s flexible.

• It holds all data in a single file (or extension files if the volume is pressed for space).

• It can handle large database sizes (up to 256 gigabytes of data).

• It can handle multiple users.

• It can operate over the network.

Starting Out

Upon receiving the ISO package, I opened it and was impressed. Sierra Software laid the manual out very well. It comes in a 3-ring binder for easy page changes. The first major section gives installation, examples, and background information. The next major section reviews important database topics and functions. The last major section goes through each function in ISO and gives an example of it.

The manual, though, was surprisingly disappointing in places (I don’t think I’ve ever seen the perfect manual). ISO is laid out so well that I felt it could have spent a little more time in places. For example, I looked at the “Getting Started” section that comprised both the installation and the examples. It seemed rather “skimpy” for such an important section.

I quickly installed ISO and tried out the examples. The examples you’ll find are of your typical flat databases. The examples demonstrated the basic functions without a great deal of overhead, but I really felt an example of hierarchical databases, sets, and some more sophisticated database queries could have been added. A database construction “walk through” example would have been great.

Please keep in mind, that I was very happy overall with ISO and the manual. Section two did a very good job of discussing the ideas and functions of an ISO database. Section three contains a reference to all ISO procedures and an example showing how it is implemented.

Basic ISO

An ISO database consists of a single physical file with the possibility of multiple “extension” files. These extension files can be considered as overflow files when disk space runs low. Within the database, several types of logical files may exist. They are as follows:

• Unstructured files - files that are accessed like data forks

• Static blocks - which are accessed like resources

• Structured records - the database portion of the database

ISO allows you to have any number or combination of these “logical” files in your database-very nice. Here is an example of how one might use all these logical file types. A drafting program may have a database of structured records for materials and costs for a particular project. The project itself could be kept in an unstructured file. Static blocks could be used to keep project specific globals such as cost totals, new views of the project, and security access variables.

As a developer, you no doubt have dealt with the data fork and resources (static blocks). I will concentrate on the database features of ISO.

Building a Database

ISO is for developing relational and flat databases. Applications that work with the databases may either be single or multi-user in design. ISO provides different resources for single-user and multi-user applications.

The development phases for creating your application are as follow:

• Design your database structure.

• Generate the schema resources that define your database with all its files, fields, keys and views.

• Generate the header files for the views you created.

• Create an application with the debugging resources ISO provides along with the schema resources created.

• Develop your application in a debugging environment.

• Finally, replace the debugging feature of your resources and code with the normal resources to generate the final application.

The Schema Editor

Resources are used to define the files and record structures of the database. One drawback of ISO is that these resources must be in the application itself. [The schema resource can also be in the database file. - Ed.] One benefit is that 4th Dimension can browse databases with an external. ISO is for specific database applications. You will not be disappointed with ISO.

A major step in database development is designing the files, fields, keys, and so on used in the database. You do this with the Schema Editor provided by ISO. I will be up front with you. The Schema Editor is quite weak in its user-interface design. It feels as if it had been created as an afterthought and is not up to par with the rest of ISO. You may want to use Rez instead to generate your resources. Still, the Schema Editor does produce a good set of reports on your schema that are handy for documentation. [Version 2.2 will have a new Schema Editor. Some of these concerns may be addressed in this new version. - Ed.]

Figure 1. Index Record IDs and Connection Fields

File Types

The first thing you do in the Schema Editor is to create file types. File types define the record structure of a file. They include field definitions, key definitions, the index record ID field, and the number of connection fields.

ISO supports a wide variety of data types, including handles to variable length data such as PICTs. Table 1 shows the supported field types. You may wish to make a copy of it and keep it handy so you do not have to search the manual again and again.

In developing a relational database, ISO uses index record IDs and connection fields. An index record ID is used for uniquely identifying each record; they are never used twice in a particular file. To establish a one-to-many relationship between two files, you include the index record ID in the parent file, and, in the child file, you specify a connection for each file in the relation. This forms a connection like in Figure 1.

For example, a database keeping track of sales contacts may have a parent file on company address information. Each record would have an index ID number. The child file may contain contact information for the individual. This contact file would contain a connection field to hold the id number of the company record. This establishes a link, or a relationship between the two files.

Keys are used to access records sequentially through your database. Although you can create sets of records and sort them anyway you wish, keys provide a quick way of accessing the records without the need for sorting.

After creating the file types, you then create the logical files and assign them a file type. More than one file can be of the same file type. Then you specify the connections between files for ISO. These connections will then aid ISO in helping maintain hierarchical relationships.

All this editing is done in a modeless environment. I suppose I am use to 4th Dimension, but I really wish the Schema Editor had a more graphical user-interface. I am consoled by the fact that schema definitions are usually done once (not!). I would recommend that you carefully design your database first before using the editor.

Each field of the database must begin on a word boundary. If you do not design your database carefully, you may end up with a lot of empty space. For example, if your database had fields that were defined as a boolean, a general byte field of 5 bytes, an array of three booleans, followed by an integer, ISO would generate the following structure to access this file type:

typedef char   Gnrl5[6];

struct TestView {
 char   b1;
 char filler1;
 Gnrl5  g1;
 char   b2to4[3];
 char   filler2;
 short  i1;
};

Note there is a byte of padding at the end of the general field and after each of the boolean fields. So a little bit of planning can save a lot of memory.

Views

Views are the final thing created in the Schema Editor. Views are how you actually access records in files. Views give you great power and flexibility. Views allow you to do the following:

• They allow you to define exactly which files, fields, and keys you will be using. This allows custom trimming and joining of files.

• They allow for automatic conversion of fields from the way they are stored to the format you need.

• They define which operations (insertion, deletion, updating, etc.) a file in that view can participate in.

• Most importantly, they allow for automatic record finding of files that have connections.

Table 1. ISO Data Types

From the previous example, if the individual contact information includes the company address information in the same view, then when the individual information is read, the company information is automatically read in. This built-in feature for relational databases is a BIG plus. It saves you plenty of coding. Views are a very powerful feature of ISO

The creation of views is the real weak point of the Schema Editor. In many places within the editor, you may drag an item over from one window to another to reduce typing duplicate information. Views are essentially duplicates of the record types you just created. Unfortunately it is here that you can’t drag a file type to a view type!

Another feature left out is the ability to shuffle around the fields of a file type or view after you have spent the time typing it in. I hope ISO is listening. These two features alone would improve the Schema Editor 200%.

Database Development

The next phase after creating the schema resources is to develop the database itself. ISO provides a large library of routines (a fact you’ll admit to as you add the many project libraries needed for compilation).

I will cover the following topics:

• Opening/Creating Databases

• Record Management

• Sets of Records

• Lock Management

• Miscellaneous Features

Opening and Creating Databases

Creating a new database or opening an existing database is as easy as opening up a file. You can assign a password to the database and specify a recovery mode at this point.

Database recovery is an extremely important issue. ISO has three types of recovery. No recovery means that transaction results are stored only in memory and actually written to the database when the transaction is completed, the memory buffer is full, or the buffer is flushed. This means that if the computer went down in the midst of a transaction, the database may be left in an unknown state.

Overflow recovery creates a physical file to keep transaction results that overflow when the memory buffer is full. This still has the possibility of losing information. Full protection keeps a full record of transactions in a physical file.

Normally when an operation is done, the results are written to the database. You may, for speed improvements, turn this off until a number of transactions have occurred and then flush this buffer. ISO contains recovery procedures to attempt to recover from a crash.

Table 2. Lock Compatibility

Record Management

Records are accessed by keys. Therefore you need to have at least one key to access records (a key can be one you defined, the insert record ID, or a connection key). To access records you do essentially the following:

1. Open the structure record file with the view you will be using.

2. Create and initialize a buffer to hold a record.

3. Select the key you will be using to access the records

4. Perform any operations needed such as finding, creating, modifying or deleting a record.

5. Release any locks that were created.

You can get to a particular record by reading the first, nth, or last record by key order. You can also find the first, last, or range of records by one or more key values. There are also many routines supplied for performing operations in looping conditions. For example, you could find the records that meet a particular criterion then delete the current record and automatically go to the next record that meets the find criterion.

Records may also be accessed in a non-sequential order by setting the current record to the record with a particular ID or address.

If a particular view is needed and is not defined in the current schema, you can dynamically create views with the needed fields and keys. These dynamically created views are temporary and are not permanently recorded in your resource fork. However, you can store these views in static blocks to be used the next time the application runs.

Records Sets

At first, I was a little confused about what sets were when I read the ISO manual. It gave me an idea of what they were, but it took me a couple of times through the manual to understand, and appreciate them more fully.

A set is simply a collection of records. Now if that seems a little obvious, let me rephrase that. A set is a structure that holds a collection of references to records in a defined order. This means that the structure does not normally hold the record data themselves. It may optionally hold an array of these collected records through a particular view, but it appears that this is really for temporary conditions such as when sorting the set.

You will use sets extensively in your search functions. ISO allows you to find records and add them to a particular set. You can then perform normal set operations with other sets such as unions, intersections, differences, and exclusive or’s. Finally, you can read the data, do the work necessary such as sorting, and release the memory to the data.

One feature that might be useful is a procedure to change the view the set is based on once the set is already built. I imagine that this routine could deallocate the memory associated with a set and change the view the set is based on. This would allow for dynamic changes of the view from a finding/sorting view to a working view. It looks like the routines are there to do it yourself, but I would rather not monkey around with structures when I don’t have complete knowledge of how they operate.

Lock Management

Lock management is a difficult issue among databases. Not only is there the overhead question associated with lock granularity (files and records may be locked with ISO and there is a method to lock fields), but with multiple users there is the problem of deadlocks. For example, a deadlock occurs in the following situation:

1. Person A locks record 1

2. Person B locks record 2,

3. Person A tries to get record 2 but fails since person B has record 2.

4. Person A then waits for Person B to record 2 to be released.

5. Person B tries to get record 1 but fails since person A has it.

6. Person B waits for person A to release record 1

DEADLOCK! These two people will wait forever since each has a resource the other needs to continue. The only recourse is for both to release their locks, wait a random amount of time, and try again.

To ensure database integrity, the safest approach is the following:

1. Attempt to gain the appropriate locks needed for all records involved in a transaction.

2. If you fail to obtain a lock, determine the reason.

a. Deadlock is detected

b. Someone else has a lock.

3. If there is a deadlock, you must release all your locks and try again.

4. If a person holds a lock, you may wait patiently and perhaps inform him of your need, or you can cancel the request.

5. If you gain all the locks you need, perform your operations quickly and release your locks.

ISO has a sophisticated method of locking and deadlock detection. There are many levels of locks. The routines that access the records have a lock parameter. You have the option of obtaining locks asynchronously. There are even routines to pass messages to other clients informing them of your need for a lock.

A lock may be requested for a file or a record. There are various lock types. Some locks may be compatible with other locks. This would allow multiple people to work on the same record/file at the same time. Table 2 shows lock permission compatibility and their meaning. To see if the locks are compatible, suppose person A has a lock on the record/file with one of the permission along the left-side of Table 2. If person B tries to lock the record/file with a permission across the top, then the lock is granted if the intersection of these 2 permissions is “Y”.

Locks may be issued on fields of a structured record file by creating a custom file lock constant. There is a maximum of 6 of these types of locks. Care must be taken that all applications that use the database honor the custom lock.

Miscellaneous Features

I have not even discussed half the features available in ISO. It is so rich in power that a single review can not cover every feature. Among them:

• There are sets of routines for managing unstructured files and static blocks.

• You can query and update a database structure. Unfortunately, there are no routines for updating the schema resources in your application.

• There are data encryption and compression routines.

• An advanced messaging system for multi-user support.

• Extensive debugging features like that of source level debuggers.

Purchase Price

I left the ISO’s purchase price last on my list of items to discuss. This package is not one of your “low-end” products. The purchase price for a single user development package is $595; for the multi-user package it is $795. I suggest that you buy the multi-user version.

Probably the biggest item that unsettled me was the royalties. Royalties on applications that use ISO are $35-$50 for corporate use, and 2-5% of revenue for commercial developers. So you will need to add this to the cost. I know I am quibbling over a small royalty when the product is so useful, but I feel that code resources, compilers, and the like should be royalty free.

I would like to reemphasize that ISO is fast and powerful. Products that are likely to require the powerful features of ISO are probably not going to quibble over royalties. Since ISO is very powerful, it can be very complex as well. ISO deals very well with the “complexity vs. power” issue. ISO makes simple tasks easy to implement. Yet, there are routines for those who wish to “run in where angels fear to tread.”

Conclusion

Inside Out II is an industrial strength database engine. It is designed for the creation of custom databases. There are no routines given to query foreign databases (using SQL for an example). The major weaknesses I felt include:

• The data dictionary is kept in the application and not with the database. A generic database application cannot easily examine databases and provide generic utilities.

• The Schema Editor is not very user-friendly.

• The product lacks hierarchical database examples.

• Your application is either multi-user with ISO’s LockServer application running, or it is single user.

The advantages I felt include:

• The view mechanism and its automatic look up of related records.

• Its simplicity in design.

• Its speed of operation.

• Its multi-user capability with messaging.

• Numerous hooks for developers.

I feel that ISO is the product for anyone developing applications with strong database needs. ISO’s price and power make it perfect for the developer audience it is aiming for.

For more information

Inside Out II

Sierra Software Innovations,923 Tahoe Blvd., Suite 102

Incline Village, NV 89451-9443

(702) 832-0300 or USA (800) 621-0631 for sales

Cost: Single User $595, Multi-user $795

(volume discounts available)

Royalties: $50/user (with special cases)