Using the V12 Xtra, Part 1

April 30, 2001
by Phillip Kerman

What it is:

An Xtra that creates structured data and lets you access and search it very quickly.

Why use it:

First, why use databases:

separation of code/data
extensible

Why use v12 specifically:

Performance speed (start up is slow but execution is fast)
Ready built for database types of things (searching, sorting, and indexing)
Cross platform
Support

Reasons to avoid:

Proprietary

This article will introduce you to the third-party Xtra called "V12 Database Engine" (or "V12DBE") made by Integration New Media. This Xtra converts structured data into a form that can be quickly accessed and searched. Basically, it offers a host of functions to perform typical database maneuvers -- and it does so with great speed.

Why Databases?

Before I answer "why use v12?" let me first suggest some reasons to use databases in your Director projects. For one thing, maintaining a database external to Director exhibits good "code-data separation" which is a worthy goal of any programmer. Separating the code (or programming ... the Lingo, if you will) from the data (the graphics specific to your project or the actual text that appears on-screen) will enable you to modify one without affecting the other. That is, you can edit or replace a graphic without touching the code (perhaps without even opening Director). There are actually many techniques to separate code from data within Director (such as storing the values for a list in a field cast member, or by making external cast files that contain just graphics). However you structure your projects, you should always try to keep the code (programming) separate from the data (the project-specific information). Storing data in an external database is one way to do this.

Using databases generally makes your project more extensible (scalable, if you will). That is, if you start with a database containing 100 records you can just as easily populate the database with 1,000 records and your program should work the same. Actually, if you plan it right, you can make one Director movie that can adapt to different databases. In theory, you can build something once and use it many times. In practice, I've found more often you can just reuse pieces of code (such as utilities and behaviors). But even code snippets are easiest to use when kept separate from the data.

Why Use V12?

So databases are good because they're extensible and can be kept separate from the code. But why use V12 specifically? I can think of many reasons. For one thing, V12DBE performs very quickly. Loading the V12 file can take several seconds but you'll likely do this only once at startup. Searching through the records in a V12 database is very fast. You can optimize searching by designating that an index is created at the time you render the V12 file. Another reason to use V12DBE is that it has countless methods built in to do almost any conceivable operation on your data. Of course, a skilled programmer could write any of these by hand (after all, someone had to write the code in V12). The point is that you don't have to reinvent the wheel. Another fact that makes V12 attractive is that it works on both Macintosh and Windows. Finally, perhaps the easiest fact to overlook is the support available from the manufacturer. Not only does V12 include extensive documentation but Integration New Media is responsive with technical help as well as periodic patches and updates.

To offer some balance, I can make one criticism of V12 which may have no impact on your needs. Namely, the V12 file format is proprietary. That fact by itself is not an issue, but your database must eventually be rendered as a V12 file. If you use a program like Access, FileMaker Pro, or even Excel to populate and maintain your database you need to convert it into a V12 file. It's not that this process is difficult but it needs to be executed after the data is locked down. It's certainly possible to make edits to your source database after it's rendered as a .v12 file using the V12DBE -- actually, there's a free utility from Integration New Media (created in Director) that allows you to do just that. The problem is that most people will prefer to use a "real" database program to make edits. Just realize any such edits to the source data means you'll have to re-render the .v12 file. It turns out that such a step isn't all bad since that's the time when your data is indexed (for faster searches). It makes sense to do such indexing "offline" because then later searches go quickly. You just need to understand how it works.

My Experiences with V12

I've used V12 for a series of projects that had similar needs (below). But with a product that has a 200 page manual and an online version compatible with Shockwave you can do much more. For example, I've never needed to add or remove records on the fly, but it is possible with V12.

I've used the V12DBE Xtra for a series of Director "catalog makers" I built for a client of mine who offers printing services (see figure 1 and 2). The connected CDs we made give sales representatives a way to search their entire product line and select items to lay out a customized catalog. Through the third-party Printomatic Xtra, the sales reps print a catalog (at 72 dpi, or as high as 300 dpi if they were connected to a PostScript printer). Alternatively, they can upload (via another third-party Xtra: Direct FTP) an order to my client's site and receive a high-resolution bound version of the catalog they just created. (The data that gets uploaded is tiny, as it's just a simple text file containing the minimum information to restore the catalog -- the product SKUs and their position on screen.) Naturally, there was a ton of Director work to get the whole project working the way we wanted. However, the actual data contained in the catalog was irrelevant. That is, if they had 400 items (as was the case with a shoe manufacturer) the program should work the same as if there were 3,200 items (as was the case with a sports clothing manufacturer). Each record in the database included fields for price, SKU, sizes, and such. My client could make edits by changing a database that remained external to the Director projector. Incidentally, all of the images were external to Director too -- their filenames simply matched the product SKUs from the database.

Figure 1: In conjunction with the V12 DBE, users can arrange products to create a customized catalog based on an inventory containing thousands of items. Additional data for each record is available through a right-click as shown on the right. (Image courtesy of Oswego Group).

Figure 2: In the Financial section of the project, users could build an order based (in spread sheet form) based on the items they included in their catalog. (Image courtesy of Oswego Group).

The V12 DBE Xtra was used in two steps on this project. First, the source database (simply a tab-delimited text file) was indexed (to facilitate fast searches) and rendered into a .v12 file. This .v12 file was then shipped with the final CD (actually, through an "online update" feature we added later, the .v12 file could be patched any time the sales rep opted to check for updates and an updated database was available). Behind the scenes, Director simply imported the latest v12 file and searches were executed at runtime through the methods (think "functions" if you want) of the V12DBE Xtra. For example, records that matched the user's criteria could be stored in a Director property list and displayed in a field on-screen. On the one hand, V12's role was small ... on the other it was critical. What V12 did was render an indexed database file that could be accessed and searched very quickly. After the database was rendered (ahead of time) all V12 did was import the data, select matching records when the user requested it, and then dump that data into a property list. In all, only a handful of methods were used but it meant that we didn't have to write tedious homemade searches (which, likely, would have performed more slowly anyway).

I built a sample program for this article that performs some standard database maneuvers on some mocked up data. In the conclusion to this article, I'll talk about how it all works.

The download for this article contains a projector and Xtras, the source Director file, and a Director movie that generates randomized data, along with the sample V12 database file in Mac (1.9MB) or Windows (1.8MB) format.

Phillip Kerman is an independent programmer, teacher, and writer. His books include Sams Teach Yourself Flash 5 in 24 Hours and ActionScripting in Flash.