May 93 - Inside Inside Out II
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.
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.