Inside Inside Out II

Laughing Water

Creating database applications on the Mac poses several challenges. An important one is choosing among the various database options currently available. You can read the ads and reviews, comparing features and performance benchmarks, but it's hard to know what it's really like to use a product until you've actually used it.

This article describes my own sense of what it's like to use Inside Out: why I chose it, what it took to learn it and how it works. If you do database applications, Inside Out is a product you should know about. So here's a jump-start.

What Is It?

Inside Out is a relational database engine for the Macintosh. Unlike programs such as FoxBase, Omnis 7, Fourth Dimension and Double Helix, it is neither a customizable database program nor a database application generator. Instead, it provides a collection of routines that implement the basic functions of a relational database, such as creating and maintaining databases, files and records. It also provides the not-so-basic functions, such as set operations, data recovery, compression, encryption and multi-user features, as well as debugging and error handling. In fact, it probably provides all the database-related capabilities you'll need, leaving you the job of writing an application around it. The routines-209 of them by my count-are provided as libraries that can be used with the Think and MPW C and Pascal compilers.

For object-oriented programmers, I'll say right away that Inside Out II does not provide support for persistent, linked objects. On the other hand, there is no reason why it cannot be used gracefully within an object-oriented application framework, and in fact it includes directions for use with MacApp.

How I Got There

Montanans wear many hats, in my case running a natural food store, developing Mac software and working for the Feathered Pipe Foundation (kind of an Esalen of the Rockies). The foundation maintains a mailing list of 10,000 and handles 400 registrations annually, along with a few hundred donations and raffle ticket sales, all of which we'd like to keep organized for future reference.

We survived without a relational database for years before it became clear that the confusion and duplicated effort cost more than making the transition from OverVUE, which barely handled our flat-file mailing list. I ruled out setting up our database in Fourth Dimension because of its reputed sloth; we were running Mac Pluses. Omnis 5 sounded like a good performer, but at the time I was looking for something more straightforward.

FoxBase was fast and reasonably priced, and the tutorial was great; but as soon as I started to program it, it seemed complex and quirky-even for something as simple as a modal dialog for entering records. (I still use FoxBase for a pricelist and find that it consistently prints my two-column report in a single column unless I first open the report layout for editing.)

In desperation, I got a copy of Double Helix, the database you're supposed to use if it's Wednesday and you need results Friday. I accepted this blow to my programmer's ego, thinking that at least we would get the job done. Besides, a comparative review showed Double Helix having the fastest multi-user benchmarks among the popular databases. We used Double Helix for a year-a painful year. It sometimes took 20 minutes to get a report on screen, and whenever a report was scrolled, the contents got recomputed. We lost data, including a day's work. Odesta sent us a three-page set of instructions for printing rosters with three names across (a trick every database but Double Helix could do), and after hours of effort my assistant and I gave up.

Double Helix requires no programming-and monkeys fly out my butt. I'd call it labyrinthine and counter-intuitive. Some of its features seemed to be unrelated accretions rather than part of a coherent design.

I read the sales literature about Inside Out, and Sierra Software's people seemed friendly and knowledgeable. I hadn't dared to consider writing a database application from scratch, even with an engine to do the dirty work. But by now there seemed to be no better choice. I was already writing application software, and to me the Mac toolbox seemed friendlier than anybody's database development environment. Besides, I could implement whatever little tricks or features I liked from each of the databases I had seen and fine-tune my application to put high performance where it mattered the most.

The Learning Curve

I bought Inside Out (version 1.3 at the time, since upgraded to 2.1) on a money-back guarantee and resolved for once to make up my mind fast enough to use the guarantee if necessary. I took the manual to a Warrant concert with my teenage daughter and was pleased to see that I could understand and retain the information while surrounded by pre-concert hubbub.

The documentation was both thorough and clear, with logical organization and a good index. It explained database theory in familiar, consistently-used terms (here was a company that called a record a record and a field a field!) and explained fully how these are implemented in Inside Out. Some features peculiar to Inside Out took a few readings and calls to tech support, but overall I could perceive a coherent, graspable design to the product. Despite its name, Inside Out's learning curve is not a moebius strip, as with Inside Mac. You can read the chapters in sequence and not get thrown by details that come later.

The Inside Out manual-some 500 pages-includes several narrative-style chapters, followed by reference sections documenting each routine by category. Each routine has an explanation of its parameters, its side effects, possible errors generated and potential pitfalls, along with sample code illustrating typical usage. Full working demo applications, with source code, are provided on disk. If all else fails, Sierra Software Innovations' technical support is outstanding. My estimate is that I got through by phone immediately eight or nine times out of ten and usually got a quick and correct answer to my problem.

There was one exception. A particularly insidious quirk involving the Think Pascal linker took months to identify and resolve. For me this was especially frustrating because the problem only appeared when my built application ran on a Mac Plus (the target machine), and the crash always came in the middle of an Inside Out routine. (By the way, source code for Inside Out routines is not provided.) Sometimes a gratuitous SysBeep in my code would remove the problem-temporarily. In any case, while the problem seemed to lie in Think Pascal, Sierra Software Innovations' technical support came up with a solution.

I was pleased with the amount of time I could put into my product, rather than into my tools. I had useful results-a basic mailing list manager-after a month or two of part-time work (which included application design, prototyping and data import). After six months the Inside Out routines seemed familiar (without breeding contempt), even though I still haven't used most of them.

How It Works

Data design

Inside Out uses a schema editing application to create resources describing your data. The schema specifies file types, including descriptions of fields and indexes. A full selection of data types can be defined, along with static blocks (non-repeating items such as company information). While fields and records are stored as fixed-length items, handle fields and unstructured blocks are also available.

The schema editor allows you to define your actual files and establish automatic connections among related files. A key feature is the ability to define views (not to be confused with MacApp views), which combine fields from one or more participating files for efficient access and simpler programming. Views also provide for automatic type conversions. Views use keys from participating files and can determine how a participating file is updated when the contents of a view buffer are changed. For example, you can automatically link customers with transactions, accessing only the pertinent customer information, and delete a transaction without deleting the customer.

Finally, the schema editor generates type declarations for the data buffers required in using your views.

You can modify schema resources-to add a field or change an index, for example-either permanently, by returning to the schema editor, or temporarily and on the fly, by issuing commands from within your application. In case changes are made to the schema resource, Inside Out includes routines for reorganizing data to match the new schema. In doing so, you can either update the data to correspond to the new schema by deleting fields if necessary, or you can upgrade the data so that no existing files or fields are discarded.

I reorganized our database dozens of times. Inside Out's initial version 2.0 release choked on this process. Fortunately, as I came to expect, Sierra Software already was working on a fix by the time I discovered the problem. My residual gripe about data reorganization is that the keys for our mailing list file consistently get redone (roughly 20 minutes on a IIsi) whether I alter them in the schema resource or not. Fortunately, reorganizing data is not a frequent task.

Writing an application

It's up to you to create an application within which Inside Out will do its work. That means writing data entry routines with whatever validation or error checking you require (Inside Out can prevent duplications, however), along with reporting and import-export routines.

Within your application you can create or open one or more databases. Each database appears as a single document icon on the Mac desktop (actually, it can be more than one if your database is large enough to spead across several volumes!). Within each database are the logical files, keys, indices and static blocks as defined in your schema resource.

Inside Out was designed for easy debugging. It includes both debug and no-debug versions of its library. Its powerful run-time debugger provides the kind of stepping and inspecting you might expect, fully exposing the high-level workings of your database routines. It also enables you to alter input parameters and enter database commands to be interpreted by the debugger. These capabilities require no modification of your source code (i.e., no compiler directives to test whether you're debugging).

Inside Out also provides customizable error-handling capabilities. Its default error handler puts up a dialog box indicating the error number, a verbal description of the problem and the routine that produced the error. This handler can be disabled or replaced by your own error handlers, which can be nested-and yes, a routine is provided for translating error codes into verbal descriptions.

So when things go wrong, Inside Out makes it easy to find out what's going on. It also enables you to select one of three recovery modes in anticipation of times when things go more seriously wrong. While you trade speed for security, in my own application I got more than enough of both. Despite my many crashes, I never managed to put our database into a corrupt state (other than Montana).

Accessing data

You will probably access most of your data as structured records (as opposed to unstructured files or static blocks). To do so requires opening a view, which is identified by name as defined in the schema editor. A view ID number is returned to reference the view. Typically you will then initialize one or more view buffers and select a key, again as defined in the schema editor. The previous key can be saved and later restored, as can the current record pointers of the files whose fields make up the view. This is important both in a multi-user context and in applications that access the same file from more than one window.

When you access your data, you must specify the kind of permission required (read-only, update or delete). Whether or not you require multi-user features, Inside Out requires you to cope with the data locking that this process represents. The downside for single-user applications is that you'll need to manage these locks, since updating and deleting cannot be done without appropriate permission, and locks that are left unreleased will cause memory leaks, however slow they may be. The upside to this is that if you ever convert to multi-user, you will have done much of the work already.

Etc.

The multi-user capabilities include user queries, customized locks, deadlock detection, a messaging system and the ability to lock external (non-Inside Out) files. Since my application is still single-user, I can't speak from experience on these features, but I would expect them to meet the same high standards that the rest of Inside Out exhibits. Similarly with encryption, compression and set operations.

Performance

My original goal in using Inside Out was to create a lean, mean data machine that would earn its keep on a Mac Plus. It took about a year of part-time work, sandwiched as it was between organic produce orders, yoga brochures and the MacApp tutorial, but I'm pleased with the results.

To illustrate (see Figure 1. Mailing list entry window.), the mailing list entry window of our database displays the usual name, address and phone numbers, along with a scrollable history that optionally displays a person's attendance, interests, donations, or more specialized mailing lists in which that person should be included. For easy navigating and spotting duplicates, it has a scrollable list of the next twelve people who follow alphabetically. (In shameless disregard of Apple's Human Interface Guidelines, the window's scroll bar is used for navigating the entire list.)

This is a fairly busy window with two scrollable lists requiring lookup and display of over a dozen records from two files. Yet the application can find and display an entry (out of 10,000) in less than a second on a Mac Plus.

In other areas the response time is excellent as well. Our progress report, showing a year's finances summarized by workshop, takes 20 seconds to come up on screen, and that report is comparable to the one that took 20 minutes using Double Helix.

Don't try this at home, but we actually used our database program as it was in development. Our data remained intact through numerous crashes and changes to our database schema. There are good reasons for backups, but Inside Out is not one of them.

But here's the best endorsement. India Supera directs the foundation and hears what users say about the database when I'm not around. A dyslexic computerphobe, she's usually inclined to wax profane when the subject comes up. But in her assessment, our database is "a blessing from heaven." The customer is always right, especially when she's your wife.

Conclusions

Inside Out II is a richly-featured, well-documented and reliable multi-user relational database engine that seems to live up to its claims. Because of its scope, it requires substantial learning time. But logical design, outstanding documentation and responsive technical support ensure that your effort will not be wasted. Inside Out's performance, capacity and flexibility are likely to meet your needs over a broad range of database applications. As a database engine, it offers possibilities for optimization and user interface customization that application-generating database programs render difficult or impossible.

Sierra Software Innovations has announced a Windows version of Inside Out. There is no current word on mainframe access, but Sierra Software has the technical expertise to make it happen. Inside Out does carry royalty fees, which can be regarded as either a nuisance or an assurance of Inside Out's continual enhancement. Judging from recent past and from Sierra Software Innovations' high profile in the developer community, Inside Out should thrive. Based on my experience, it deserves to thrive.