The Benefits of Database Engines for Macromedia Director

V12 Database Engine: The Missing Link

Integration New Media, Inc.

Copyright © 1998, Paul Hemmer, Interactive Digital Communications, Inc.

The following trademarks are used throughout this document: Director, Xtra and Lingo are trademarks of
Macromedia, Inc., FileMaker Pro is a trademark of Claris corp., Windows, Access, Excel and DOS are
trademarks of Microsoft corp., Macintosh is a trademark of Apple corp., 4

th

Dimension is a trademark of

ACI. Integration New Media, Inc. and V12-DBE are registered trademarks of Integration New Media,
Inc.

Today’s multimedia applications demand robust data manipulation and user

interaction capabilities. To provide such functionality to the end-user, an application

must be “smart” in that it should have the ability to store and retrieve dynamic, interrelated

pieces of data. Macromedia Director is the leading multimedia development tool for

developers with both artistic and programming backgrounds alike. While Director as a

development environment is extremely powerful, there are several key areas of

functionality which are generally lacking, such as printing, and reading and writing to files.

Many time-critical tasks simply could not be implemented efficiently with Lingo,

Director’s programming language. Director was originally designed as an interactive

animation tool, and as such, does not inherently support some of the more robust

functions needed to develop powerful, data-driven applications. However, Macromedia

Director is designed in such a way that Xtras, or external components can be developed

to extend Director’s functionality. This allows third parties to develop specialized

components which enhance the core Director functionality. Developers are increasingly

combining the powerful animation engine found in Director with advanced Lingo to

develop robust, data-driven applications. As such, the variety of available Xtras for

Director is growing every day. There are four main types of Xtras which can be

developed for Director. These are Lingo Xtras, Tool Xtras, Transition Xtras and Cast

Xtras. Each type of Xtra represents an extension to the corresponding core Director

functionality. One key component needed to utilize Director as a robust, data-driven

software development application is a database.

What is a Database?

A

database is a collection of information which can be structured and sorted. In a

database, data is stored in

records. Each record represents a collection of fields. For

example, when the record keeping personnel at a university are updating a students course

grades, the form which is to hold those grades can be considered a record. Each

item on

that record (for example, student name, home address, grade point average, year level

etc.) represents a field of that record. Each distinct drawer in a filing cabinet that the

schools registrar uses to hold student records is analogous to a

table in a database. Such a

table in a database might be labeled “

Grades” as would the filing cabinet in the student

records office. For every table in a database

, there can exist one or more indexes. A

probable index value for student records would be the last name of the student. In other

words, an index represents the piece of information contained in each record which is used

when searching for a specific record or records. Upon arriving at the registrar’s office of a

university, the receptionist would probably ask for your last name and then proceed to

search through the filing cabinets which are organized alphabetically by last name. Doing

so allows the receptionist to quickly locate your registration information forms. When a

field

in a table of a database is indexed, the database engine maintains an internal listing of

values so that it can search for a specific record quickly. A database simply represents a

collection of tables. See Figure 1.

Figure 1.

Notice that a university does not use one single form to record every piece of information

about your student history. Often times several forms will exist to hold the smaller sets of

related information your school might need to know about you. It wouldn’t make sense

to have every bit of your information duplicated on every new form. If such a filing system

were in use, one might refer to it as

flat, in that every form a school used would contain

every piece of information pertaining to each student. A more sophisticated approach

would be to break information into separate

tables such that related data is stored

together in a smaller container, rather than being jumbled in with all the other pieces of

data. If a university uses several different forms, each with a distinct set of related fields,

and only the last name in common between the forms, this could be referred to as a

relational filing system. In the database world, such a system would be called a relational

database. Figure 2 represents the distinction between a flat and a relational database. The

flat database on the upper left represents a large table containing every piece of data

concerning each student. The relational database to the lower right represents the

separation of data into distinct tables, with only one duplicated piece of data acting as a

cross-reference between the two tables. In this case, the student’s last name would be

duplicated on each record, but nothing else.

Figure 2.

Such a system makes it easier to manage related pieces of information. More importantly,

it allows one to cross reference a single piece of information to a different set of records.

For example, the last name of a student on a registration form could be used as a cross

reference to locate final exam grades from a previous term in the appropriate filing

cabinet.

Imagine if such a data management system could be built into your multimedia

applications. Suddenly your applications could “come alive” and have the ability to

remember and update all kinds of information. You could develop interactive product

catalogs which could be dynamically updated with new product information, current

inventory status and pricing information. Full-text indexing features can be used to type in

a complete or partial product name and the database could quickly lookup more

information such as availability status and pricing and ordering information. A client could

maintain a database of customers and quickly retrieve account status, ordering histories,

contact lists etc. One might also want to search for all customers who have ever ordered a

given product or for all customers who have placed orders in the past five months for

example. A database allows one to search for records based on multiple criteria. For

example, a user could easily ask the database for a list of everybody who has ordered

“Product A” within the past three weeks. Corporate sales people could use such a system

to store presentation materials. A database of presentation slides could be searched and

sorted based on dynamic criteria. For example, all slides containing information about a

given product could be quickly retrieved, sorted and displayed. Multimedia training tools,

or computer-based training (CBT) products could use such a data management system to

maintain student progress information. The administrator of a CBT application could then

use the database to perform a search for information relating to a specific student. If such

a data management system were a component in your application, the possibilities would

be limitless. Fortunately such a database system exists, and it’s called V12 Database

Engine, by Integration New Media, Inc.

V12 Database Engine

V12 Database Engine (V12-DBE) from Integration New Media Inc., is an Xtra for

Macromedia Director which affords multimedia developers the power to satisfy the

increasingly dynamic demands of their clients. V12-DBE is used with Macromedia

Director 5.x and 6.x. It is fully compatible with Macintosh System 7.x and 8.x, Windows

3.1 and 3.11, and Windows 95.

Historically, multimedia applications have been little more than glorified slide

shows. Data has been presented to the user through flashy interfaces utilizing colorful

graphics, sound and video. Such multimedia applications grab the users attention while

presenting to them a predefined information set. For developers who wish to utilize

Macromedia Director to develop mostly static multimedia pieces, the core functionality is

quite suitable. However, today’s clients are accustomed to the robust, data-driven

software applications found on the market today. Increasingly, clients are demanding more

from the multimedia applications which they contract developers to produce. The core

functionality provided by Director and Lingo can be used to provide dynamic data storage

and retrieval. However, the extent to which such functionality can be used effectively and

efficiently is minimal, and the shear complexity of developing such applications using only

the core functionality found in Director can become overwhelming. Now with the simple

extension of Director with V12-DBE as a dedicated database engine, Director applications

can be as robust and intelligent as today’s leading applications. When a developer is

contemplating the decision to utilize a dedicated database engine as a major component in

a multimedia application, several questions will undoubtedly arise. At a time where data-

driven multimedia applications are still outweighed in number by the less robust

multimedia “pieces” which generally represent more artistic promotional themes, it can be

difficult to see the inherent usefulness of using a database to drive an application. One

can’t help but ask when and where such an extension could be useful. Any multimedia

application relating to games, personnel tracking, interactive product catalogs, inventory

tracking, reporting systems or training material is going to require at least a rudimentary

level of data storage and retrieval functionality. Even when such a need clearly exists,

developers are often reluctant to turn to a third party component when the job could

seemingly be accomplished adequately with Director and Lingo alone. For simple data

storage, such as retaining the names and performance scores of a few people in a gaming

application, or for storing progress indicators for a few students in a computer-based

training application, Director cast members and Lingo can be used quite effectively.

However, it is important to note that the ability for such applications to grow and perform

properly is restricted by the current state of the application. While Director cast members

and Lingo perform quite suitably when the application specification requires the storage of

only a few names and numbers, it is quite possible that in the future the size and

complexity of the data being stored will grow. As such growth occurs and the size of the

Director cast members needed to store such information grows, increasing demands are

going to be placed upon the system to keep up. If any kind of complex queries or data

sorting capabilities are required, coding such functionality with Lingo will become

overwhelming, as extensive knowledge of the Boolean logic inherent in such data

manipulation programming will be required. This functionality is built right into V12-DBE.

On a more abstract level, if a large scale, data-driven application is going to be easily

maintained, it will require a high level of system-wide cohesion. This means that data

should be stored in a common location and manipulated by a common code base. Taking a

less cohesive approach to developing a complex software system will only cause problems

when it needs to be debugged or upgraded. When relying on Director cast members and

Lingo alone to provide the functionality necessary for such a data-driven application to

perform, system-wide cohesion will be reduced as the data is spread across Director casts

and associated code is spread across multiple levels of scripts. V12-DBE represents a

simple to use extension to Director which eliminates the need to utilize cast members and

custom Lingo code for the data storage and retrieval power your applications demand.

V12-DBE acts as the central location in which data is stored, and its associated methods

provide a uniform and consistent code base by which data can be accessed.

How does it work?

V12-DBE consists of two Xtras. The

database Xtra and the table Xtra. Used

together, these two components create a powerful database environment for your Director

applications. A single instance of the

database Xtra must be used to create a new V12

database or to open an existing V12 database. For each table in your database, one

instance of the

table Xtra is required. Database files can be created in a number of popular

database environments such as FileMaker Pro, MS Excel, MS Access, FoxPro 5.0 or

earlier files, 4

th

Dimension, and Dbase V or earlier. Files created in any of these database

environments can later be imported into a V12 database within the Director environment.

V12-DBE is also capable of exporting databases as TEXT or DBF files, which can then be

re-opened in many of the popular database environments. The benefit in such a system lies

in the fact that databases can be developed and modified in many popular database

environments which use a graphical user interface. This eliminates the need to design and

implement your databases with Lingo, a task which can be rather daunting to someone

lacking advanced knowledge of database structures.

V12-DBE offers several powerful features. V12-DBE is fully scriptable. All V12-

DBE features can be used both at runtime and authoring time, except for database

creation and cloning, which require a licensed copy of V12-DBE to work at runtime.

Tasks such as database creation and data importing can be fully automated. Several easy

to use and well documented commands allow you to manipulate and view the records in

your database through Lingo scripts. Custom Lingo handlers can be written using the

robust set of Lingo methods provided by V12-DBE. Several data types are also

supported. A field in a V12-DBE table can hold values of type

string, integer, float, date

and

media. The format of date values can be fully customized to reflect the variety of

formats in which dates are internationally displayed. V12-DBE is unique in that fields of

type

media can hold pictures, sounds, RTF objects, film loops and any media type that can

be stored in a Director Castlib. Fields of type

media cannot, however, hold Digital Videos.

This is solely due to Director’s Lingo API limitation. V12-DBE supports a number of

predefined custom string types, including Swedish

, Spanish and Hebrew. Custom string

types enable you to sort and compare all single-byte languages properly. Each string type

has a predefined set of rules which determine how search criteria will act upon them.

Languages such as French, German, Italian and Dutch are naturally sorted properly.

Custom string type rule sets are fully documented, which makes it easy to determine

exactly how your search criteria will act upon a record set. There’s no guessing involved.

Dynamic Data Binding

V12-DBE has the unique ability for Director cast members to be dynamically

“bound” to fields in a V12-DBE table. When a Director cast member is bound to a field in

a V12-DBE table, the value stored in the field is continuously updated and displayed in the

associated Director cast member. In a sense, this represents a “live link” between a field in

a V12-DBE table and a Director cast member. Data Binding can be done automatically or

at the discretion of the developer. This flexibility greatly enhances the overall appeal of

V12-DBE. Once bound, a Director cast member automatically displays and updates the

content of its associated field for the current record. This can be extremely useful in that it

can eliminate the need to write Lingo scripts to get and set the values of the current

record.

Full Text Indexing

V12-DBE tables can be indexed, both by value and with full-text indexes. Indexes

are useful for searching and sorting data in large tables. When the size of a record set

grows, indexes can substantially increase data access speeds. V12-DBE supports up to

128 indexes per database. V12-DBE uses several operators for implementing full-text

indexing. The

Start operator finds all records that start with a given sub-string. For

example: "field X

starts with hello" locates "Hello word" but not "Say hello!" The

Contains operator finds all records that contain a given sub-string. For example: "field X

contains burg" locates "Cheeseburger". The WordStarts operator finds all records that

contain words that start with a given sub-string. Example: "field X

WordStarts ham"

locates "Great hamburgers", "Green eggs and ham" and "Hammer", but not "Champion".

The

WordEquals operator finds all records that contain words that match exactly a given

substring. For example: "field X

WordEquals ham" locates "Green eggs and ham" but not

"Hammer". An example of an application where such indexing would be useful is an

interactive help file. In a help file, the ability for a user to enter a portion of the topic they

are looking for, eliminates the need for a user to remember exact phrases or spellings in

order to find the desired information. The ability to implement such flexible full-text

indexes is extremely powerful, and can prove very useful in many application domains.

Searching

Querying, or searching for specific sets of data in a V12 database is a somewhat different

process than one familiar with conventional database engines might be accustomed to. The

difficult to write SQL statements required in most database environments are replaced by

a method called

mSetCriteria provided by V12-DBE which allows a Lingo script to define

a single record selection criteria. Unlike complex SQL statements required to build search

expressions in many database environments,

mSetCriteria expressions can be executed in

succession to narrow down search criteria. For example, a search could be defined such

that records for all customers who ordered a given product between two dates are

returned. As with most database environments, results of search expressions exist as

distinct tables. See Figure 3.

Figure 3.

Such a straightforward process of building and executing search expressions turns even

the most complex searches into an easily accomplished task. Following the execution of a

database query, the

mGetSelection method allows the retrieval of search results as Lingo

lists - both regular lists and property lists. This makes the Lingo based manipulation of

search results extremely easy.

Error Detection and Defensive Programming

V12-DBE provides powerful error detection capabilities. Two methods,

V12Status and V12Error can be used to confirm each step of database creation and

handling. By following each call to a V12-DBE method with a call to these methods, a

developer can use Director debugging tools such as the

Watcher and the Debugger to

precisely pinpoint any problem areas in his or her Lingo scripts. V12-DBE is designed in

such a way that all calls to V12-DBE methods will return a code that can be interpreted by

V12Status and V12Error. This can provide comprehensive information pertaining to what

might have gone wrong when a call fails. Generally these two methods are used together

in a single

checkError() function which can be called after each call to a V12-DBE

method.

The error checking tools provided by V12-DBE are invaluable during the

development process for tracking down errors and raising an alert when an error does

occur.

V12-DBE Behaviors for Director

V12-DBE Behaviors Library allows a developer to simply drag and drop database

functionality into multimedia applications to create simple database-driven user interfaces

without writing a single line of Lingo code. These Behaviors make it simple for any

developer, regardless of his or her level of Lingo knowledge, to implement any of the

features of V12-DBE needed to incorporate it with a Graphical User Interface.

V12-DBE Samplers

Integration New Media makes available several “Samplers” on their web site

(

http://www.integration.qc.ca/downloads

) which serve to illustrate key concepts, and

stimulate creative insights into possible applications of V12-DBE as an extension of the

Director development environment. There are several types of functionality common to

most applications utilizing a database, and sample movies are available to illustrate the

following concepts :

•

Performing searches and displaying results as each letter in a

keyword field is typed, as in help file indexes.

•

Full-text indexes using V12-DBE.

•

Displaying and browsing multiple fields of a single record at once.

•

Importing external media files.

These represent only a few of the Samplers provided by Integration New Media, Inc. on

their corporate web site. Integration New Media encourages members of the V12

community to make contributions to the site such that other developers can see what new

techniques are being utilized to use V12-DBE to it’s fullest capacity.

V12-DBE is an extremely powerful, comprehensive, user friendly and cross-

platform database engine designed for use with Macromedia Director. Vahe Kassardjian,

President of Integration New Media states,

“V12 allows one to structure his work from the start, therefore cutting out

an unbelievable amount of programming time, leaving more time for

creative effort, as well as allowing for rapid updates.”

As a powerful extension to Director, V12-DBE truly is the missing link needed to

make your multimedia applications come alive.