Hide full article
Let me not beat around the bush. ProVue Panorama is the best general database program I've ever used.
<http://www.provue.com/panorama.html>
Granted, I may not be a typical database user. I'm not running an "enterprise solution" - I just want my information kept safe and accessible. But for such purposes I'm so happy with Panorama that I have moved all my data into it, reproducing all the functionality I previously achieved using FileMaker, Helix, and HyperCard. My address book, my inventories of books and LPs, my diary, even my system for archiving email digests as individual messages and reading them by thread - all these are now Panorama files. Plus, Panorama is externally scriptable, so I'm using it to store catalog data and then driving it with Frontier to transform that data into Web pages.
<http://www.ojai.net/threadsofjoy/wool.html>
<http://db.tidbits.com/series/1168>
<http://db.tidbits.com/article/05814>
<http://db.tidbits.com/article/04075>
<http://db.tidbits.com/series/1134>
Panorama has been available on the Mac since 1988 (or 1984 if you count its predecessor, OverVue); but I don't think I'd have liked earlier versions as much. The new version, Panorama 4, includes many changes that bring it to a state of pleasing maturity. It is now PowerPC-native and cross-platform with Windows. The recent maintenance release, 4.0.1, incorporates some further features and fixes some important bugs.
The Big Picture -- Panorama is RAM-based: it holds open databases entirely in memory. Obviously if you haven't enough memory to hold your data, you can't use Panorama. But RAM is now cheap and plentiful, and Panorama doesn't waste it: a database of half a million names and addresses will work fine if you give Panorama 32 MB. And the RAM-based approach has three great virtues:
Speed. Access to data is instant; sorting, or running through all your data gathering information or performing some calculated change on a field, is lightning-fast.
Simplicity. The speed means there's no need for indexes; this in turn contributes to speed, as there's no double-bookkeeping when a value is changed. A database file consists simply of its data, plus some display information in a compact binary form. Panorama's files are therefore small (typically less than half the size of the same information kept in FileMaker). They're also safe - I can see my data with a text editor, and could extract it in an emergency.
Volatility. Think how many times you've accidentally changed some data in FileMaker, only to discover it has written the change out to disk. Panorama writes nothing to disk until you say so. Combined with Panorama's raw speed, this encourages free experimentation - if something goes wrong, you can always revert to the saved version. So volatility is a virtue. Indeed, volatile manipulation of data is a standard Panorama technique; you might add a field, fill it with data, do something based on the results, and delete the field again, without ever saving.
Ways of Seeing -- Panorama provides three ways of looking at a database: the data sheet, forms, and the design sheet.
The data sheet is essentially a grid or table showing all your data: each row is a record, each column is a field. The data sheet is a great comfort and convenience; it's the simplest place to edit data, and you can always return to it for an overview of your data to make sure it's safe.
Forms are custom views that you create. They're like windows in an application. What data appears in a form, and how, is up to you. You design a form in a graphical mode whose features in some ways surpass most drawing programs I've used; for example, there are truly superb ways to select an object and adjust its size precisely even in very cluttered surroundings, and to adjust multiple objects together. You're given a huge repertory of interface widgets - editable and non-editable fields, buttons, pop-up menus, combo boxes, scrolling lists, table-like matrixes, scrollbars, balloon help, charts, images, movies, and even a remarkably full-featured styled-text editor.
A form displays data either from one record at a time or from all records arranged vertically. Multiple forms can be open at once; whatever record is displayed or selected in one is automatically displayed or selected in all the others as well. This is a splendid feature (especially in contrast to the contortions you have to go through to make the same thing happen in Helix).
The design sheet presents the schema of the database: each row is a field, each column is a field property. It's a good place to add or delete fields and to study their workings. Certain structural actions work best here; and having the information spread out before you can be very helpful (contrast the difficulty of drilling into your database's structure with dialogs in FileMaker).
Panorama is big, but there's no need to learn all of it to start using it effectively. Your journey into its workings may be envisioned in terms of three levels of programming; exactly how you work with your data depends largely on what level of programming you're willing to do. I'll discuss these three levels in turn.
No Programming -- The basic manual activity is of course to enter and edit data. Panorama has many shortcuts to help you. As you type, fields can automatically capitalize and format themselves, auto-initialize themselves, check for duplicates, perform some mild validation, and even auto-complete your typing based on existing values.
Records can be sorted and sub-sorted. They can be manually rearranged - copied, pasted, duplicated, moved one position forward or backward. They can be deleted, individually or en masse.
You can search records in two ways - successively (called Finding), and by temporarily hiding non-matches (called Selecting). You can construct a complex search to start with, but you don't have to; instead, you can do a search, and then refine the results with another, and so on. There's no regular-expression support, which is a pity; but there are a couple of mild wildcard characters.
Panorama can generate summaries and sub-summaries using such operations as total, average, count, and running difference. The summaries are themselves records; you can then show or hide the raw data, making it easy to inspect your results. When you're done with your summaries you just delete them - a good example of Panorama's "volatile" mindset. The implementation is very like an Excel spreadsheet. In fact, like an Excel spreadsheet, you can even generate crosstabulations and graphs! And again, Panorama's speed means there's virtually no penalty for analyzing your data using these features.
Data can be munged in further ways. You can do a find-and-replace within a field, in one record or all of them. You can apply sequential auto-numbering throughout a field. You can copy field values into the empty fields below them (called Propagate), or reverse this and put an empty value in any field where the value above is identical (Unpropagate). You can search for duplicates and easily eliminate them.
Repeating fields (with multiple values per record) are handled well. Each repetition is a separate field, but the form of the field name (e.g. Price1, Price2, and so on) tells Panorama they go together. If you make a structural change to one, Panorama offers to change them all. The result is that in simple one-to-many situations your database needn't be relational.
Panorama can also print labels and reports, whose layout and details can be greatly customized.
Functional Programming -- Panorama provides some 200 built-in functions for manipulating data. In various contexts, you can type expressions consisting of one or more of these functions; a hierarchical menu lists them all, to help you type them. There are functions to perform arithmetical, statistical, logical, or date operations, or manipulate text. Other functions get information about the database, access the clipboard, read files and resource forks, and transform graphical structures (these are most likely to be used as part of a procedural program). Finally, "lookup" functions match information between databases, making them relational.
A typical use of functional programming is to associate a functional expression with a field. Just as in a spreadsheet, when a value on which the function depends changes, the new result becomes the field's value. (Such a field is not, however, a "calculation field." The function's action merely enters a value; you are free to enter a different value manually.) You can also use formulas to generate values throughout a field, to do a find-and-replace, or to construct a complex search expression.
Formulas can also be used in forms. A text-display widget, for example, can display the result of a formula (e.g., the firstname field, a space, and the lastname field). In contrast to FileMaker, there is no need to overpopulate your data with extra calculation fields; the calculation takes place in the form itself, where it belongs.
Procedural Programming -- Panorama's second programming language is procedural, meaning that scripts (procedures) constructed with it consist of a sequence of commands. The language is unique to Panorama, but you can create automations without actually learning it: a menu listing all procedure commands helps you enter them, and a recording facility lets you translate many actions into procedural commands. Still, it's worth learning, since despite a certain crude simplicity it's extremely powerful and quite ingenious. You type a procedure as text in an ordinary window - a huge relief, in contrast to FileMaker's dialog-based script construction. There are facilities for interactive debugging.
Procedural commands can modify and manipulate data, database structure, and even interface widgets in forms. They can put up customizable dialogs, open and close databases, manipulate windows, import and export data, and manipulate file data and resources. In short, procedural commands can make Panorama do just about anything you could make it do with the mouse and keyboard, and then some. Procedural commands are also the key to scripting Panorama externally; you construct a procedure as text and send it to Panorama with the "do script" AppleScript command.
Procedures can define variables. These can have any of five different scopes, ranging from purely local and temporary to a "permanent" variable that is automatically saved with the database. (Contrast FileMaker, whose only variables are fields.) You can set a variable's value through assignment or through a form widget, and you can use it in a formula. Thus variables are an important way to collect information and pass it around. For example, a pop-up menu widget gets its menu items from a variable; change that variable's value and you change what items will appear the next time the user pops up the menu.
Procedures can be triggered in various ways. They can be chosen from a customizable menu. They can be associated with an interface widget in a form, such as when a button is pressed. There are also procedure triggers that respond to more indirect user actions. For instance, recall our example about the text widget that displays the firstname field, a space, and the lastname field. One might attach a procedure to be triggered when the user finishes editing the text; the procedure would break up the text and assign its pieces to the firstname field and the lastname field. Thus the display and entry of a name is presented to the user naturally, as a whole name, even though storage behind the scenes uses a firstname and a lastname field.
That example gives only an inkling of what's possible. With the procedural language plus the form widgets you're essentially writing a programmed interface with a database back end (like HyperCard); the range of what you can do is astounding. Panorama comes with various tools and examples that show this. There's a calendar/reminder tool, a calculator, a stopwatch, and a mail-merge tool; there are tools to help import and export data, and to arrange or resize your database's windows; there are tools for testing functions, for listing a form's interface widgets, and for searching your procedure code. Many of these tools don't seem like databases, but that's what they are - even the Panorama installer is a Panorama database! Thus the Panorama milieu is a tool-making environment supplemented by tools made in that environment (again, extremely HyperCard-like).
Procedures can call one another and can contain sub-procedures. A value in a procedure can be an expression constructed from the functional language. But there's a major asymmetry: a functional expression cannot call a procedure. I regard this as a major flaw in Panorama, and quite unnecessary.
Learning Curve -- Getting started with Panorama is easy. It's one of those programs where 80 percent of users probably use only 20 percent of the power, and you can pick up that 20 percent quickly. There's a 200-page PDF tutorial, or you can watch a couple of hours of charmingly amateurish QuickTime movies that will have you up and running in no time. There are also 70 example databases.
Deeper understanding, though, comes only at the expense of mind-numbing study and wrist-numbing mouse-clicking. Panorama is accompanied by an 1,800-page manual and a 900-page reference, both PDFs. This material, while engagingly written, is tedious, partly for its sheer bulk, and partly because the order is uninstructive (though mostly logical). For example, although the reference explains built-in procedures and functions, many important aspects of the language, such as output patterns and commands sent to interface widgets, are documented only in scattered locations in the manual.
Most other matters end up scattered too; the whole manual reads like a gigantic forward reference, where we're forever being told that such-and-such a matter will be explained eventually, but it takes forever to get there. For instance, take text editor widgets. The important facts about them appear in four widely separated regions of the manual! The whole manual is like this; it needs reorganization by a teacher.
Conclusions -- Have I communicated just what I find so wonderful about this program? It's the fact that my data feels safe and is easy to check on. It's the ingenious anticipation of my needs. It's how the workings of my databases are easy to track down. It's the generosity of the supplied examples. It's the fact that easy things are easy and hard things are not that hard, in contrast with other database programs where you have to dance all around the moon to get certain things done. Ultimately, it's the total programmability, which makes me feel I could build anything I like, even to the point of rendering redundant several other programs I already have. (For example, I suspect you could build a better Boswell - a text snippet keeper - using Panorama.)
<http://db.tidbits.com/article/06441>
Still, Panorama is quirky. The main trouble seems to be that Panorama's core dates back to a time when many Macintosh conventions weren't yet fixed, combined with a reluctance on ProVue's part to change things later on. For example, there is no File -> New menu item; Command-W closes a database, not merely a window; to cancel data entry in a field, you type Command-Period, not Escape (but this is fixed in 4.0.1). The form widgets are not Appearance Manager-savvy, dialogs are maddeningly modal, and there are many tiny cosmetic interface glitches. Some features must be accessed by holding a modifier as you choose a menu item, but the menu item doesn't change to tell you what will happen. Many form widgets have been superseded by newer versions, but the older versions are still present and are used by default. In general, Panorama seems to have grown by accretion rather than evolution.
Another problem is that many potential users may be put off by the lack of compatibility with existing tools. Even folks who don't like their current database program may not wish to switch when a significant investment is involved. A friend to whom I raved about Panorama pointed out that a Panorama that used a FileMaker-compatible scripting object model would be easy for him to switch to, but this Panorama is not. Similarly, all your SQL knowledge won't do you a bit of good in working with Panorama. Finally, there's the issue of Web connectivity; ProVue makes a WebSTAR plug-in and a utility for querying databases and returning HTML, and this technology is used in some very fast dynamic Web pages, but it isn't part of the basic package, and it's very hard to learn that it exists (you get it by purchasing a "Conference CD", but a search at ProVue's own Web site for "CGI" turns up nothing).
<http://www.provue.com/Documents/ProVUE_Conf_CD_ Sets/ProVUE_Conf_CD_Sets.html>
These things are a pity, but from my perspective they are outweighed by Panorama's virtues. This program rewards and deserves exploration. I'm delighted with it, and am using it more and more heavily. I recommend it to your consideration.
Panorama requires a PowerPC Macintosh and System 7.6 or later. On Mac OS X, it runs fine under Classic. The base cost of Panorama is $300, though complete pricing is complex. The Image Pack (to display non-PICT images) is $15. The Personal License - allowing Panorama to be used on more than one machine - is $30. Various options for distributing databases to other users without their having to purchase a full version of Panorama are available; for example, for $25 you can make a database run as freeware in conjunction with a free version of Panorama. There is also a multi-user client/server version available, for an extra charge which starts at about $125 per user and gets cheaper (per user) as the number of users rises. You can download and try an unregistered full-featured version that puts up an annoying dialog whenever you save a database larger than 250 records. The basic download is about 4 MB; a full installation (including all documentation and examples) occupies about 80 MB of hard disk.
<http://www.provue.com/download.html>
