1. Introducing FileFlex

FileFlex is the ragingly-fast, cross-platform, relational database engine for multimedia, designed for creating CD-ROMs, kiosks, and interactive multimedia projects. FileFlex is fully xBASE/dBASE
compatible. FileFlex and FoxPro (and other xBASE-compatible software) can directly exchange files without conversion. FileFlex requires no special drivers and only 100K of RAM--allowing you to add relational database capabilities to their projects at virtually no cost in system resources. FileFlex also includes dynamic, on-the-fly office-quality encryption and full-text search and retrieval capabilities. FileFlex Lite is bundled with Director 5, allowing Director users to add database capabilities to their multimedia productions.

FileFlex 2.0 Features and Benefits

FileFlex 2.0 features include: FileFlex is a very tight code library. It is distributed as a loadable code module (a DLL under Windows and a code resource or shared library on the Macintosh). As a result, there's no need for interapplication communications and you don't have to worry about special installations for alternate applications. FileFlex also does not require any special drivers. Once you install the one code module, FileFlex is available.

FileFlex Lite Edition

When you get Director 5 from Macromedia, you'll also get a copy of FileFlex Lite. FileFlex Lite is a complete version of FileFlex with only one limitation: you can only access the first 1,000 records of a database. If you want access to the full professional edition of FileFlex, you can purchase it directly from Component at www.component-net.com.

Users of FileFlex Lite must contact Macromedia at 415-252-9080 (Fax 415-703-0924) for technical support.

Please do not call Component. We're just not equipped to accept technical support calls from all of Macromedia's customers.

FileFlex Professional Edition

When you buy the full FileFlex from Component Software, you're getting the Professional Edition of the product. You can tell you've got the professional edition because your DBVersion() command will return a "2.0P"rather than a "2.0L" in the version string.

The professional edition is the complete software, including the ability to access an unlimited number of records, documentation, detailed technical information, technical support, access to E-mail feedback channels, and development tools. This "whole product" is called the FileFlex professional edition and if you're reading this document and have purchased FileFlex from Component, you own the professional edition.

You are licensed to run FileFlex on one personal computer per copy of FileFlex professional edition purchased. If there is more than one person in your organization developing using FileFlex, please purchase a professional edition for each person.

FileFlex System Capacities

The Difference Between FileFlex and a Full DBMS

FileFlex is a database product in a market unbelievably overcrowded with database tools and dominated by some of the largest software companies-including behemoths Microsoft and Oracle. These are not competitors you want to meet even in broad daylight in a deserted alley!

Yet FileFlex is amazingly successful. Why? Is it because it's a better product than those produced by the big boys? Is it because our marketing is vastly superior? Is it because we're entrenched in some industry-critical installations?

If you answered "No" to all of these, you'd be correct. In fact, the "Yes" answer applies to our competitors. Had we attempted to compete with them on their terms, we would have been squashed like a bug. And justifiably so. FileFlex has neither the engineering technology nor the marketing muscle to compete in the big leagues. But it is a highly successful farm league player.

The big products (names like FoxPro, dBASE, Oracle, Ingres, Informix, Access, 4th Dimension, FileMaker Pro) are general purpose database products. They contain all the features you need to build whatever you want. Not only do they manage the data, but they have tools for building the interface (how the computer interacts with you), reports, and controlling operation (usually a built in programming language). FileFlex has none of that. FileFlex just manages data. The picture below shows how much more of the database "solution"our competitors provide:



So, how do we compete? We have different customers. The big market in databases is in full solutions (i.e., accounting systems, order processing, banking). But there's also a market (much smaller!) that just needs to get at and retrieve data. The buyers in this market are programmers and developers themselves and their desire is to embed data access technology inside their own products and solutions (without becoming beholden to some large monolithic technology provider).

The overall database market is in the billions. The total market for embedded databases is way under $50 million. Very few players are in the embedded market, so we're able to make money. Many of the big database systems, while most effective in the hands of programmers, can still be used by almost anyone. But to use FileFlex, you must be a bona-fide, card-carrying propeller-head. No non-nerds need apply.

If you haven't guessed already, nichemanship (playing to market niches) is an obstacle avoidance strategy that works. When it comes to databases, our competitors were after the mainstream, so we went after developers.

Interfacing FileFlex to Host Environments

In addition to the normal stuff that you get in a programmer's manual, the purpose of this section is to help you understand some of the design decisions that went on behind creating FileFlex' cross-platform architecture. 
                      Native Operating System/Architecture
Development     -----------------------------------------------
Environment        MacOS/PPC   MacOS/68K   Win95/NT   Win3.1   
-----------     -----------------------------------------------
Director 5           Yes          Yes         Yes       Yes
Director 4         Emulated       Yes       16-bit      Yes
Authorware 3       Emulated       Yes       Planned    Planned 
HyperCard 2.3      Emulated       Yes
SuperCard 2.5      Emulated       Yes       Planned    Planned 
Metrowerks C       Planned      Planned

I've been down this path before with a number of other projects and products, both for Component and other companies. I know that a straight port can often result in a working piece of code for one version and unmaintainable code for versions later on. This happens especially if you have two different sets of source code. Changes made to one somehow have to be properly rippled back to the other and, 99 times out of 100, some critical sets of changes just don't make it. This is one very good reason why it often takes much longer for a piece of software on one platform to follow a piece of software on the other. I was unwilling to incur the overhead cost and pain of maintaining lots of different sets of source code for each of the products that FileFlex runs inside. From that desire came the first major decision and major architectural change in FileFlex, the need for a common source code model.

Common Source Code Model

Briefly, a common source code model means that there is one body of source code used to generate all of the individual different versions of the product. As a result, a change that's made in a source file doesn't have to be duplicated in an identical source file on another system. For any given piece of code, there is only one individual source code file.

This architecture necessitated the breaking up of FileFlex internal structure in such a way that it allowed for two moving targets. The first moving target, at the bottom end of FileFlex, is the operating system interface. This would include the various function and toolbox calls used to do things like access files, check timing, move record pointers around, and so forth. The series of routines that control this needed to be rebuilt into, for all intents and purposes, a virtual machine or a Virtual Operating System Layer. In other words, at some point in FileFlex a function call is made to access, say, disk data. That function call, however, knows to tell the operating system layer on the Macintosh to issue a toolbox call and under Windows to issue a different kind of File I/O routine.

But there was another important requirement, and that was that this Virtual Operating System Layer must not incur a speed hit, and must not increase the size of the resulting binary or memory requirements in any measurable way. As a result the Virtual Operating System Layer is controlled entirely at compile time by setting what are called #ifdefs. #Ifdefs, when set one way, cause the compiler to compile one bank of source code and, when set another way, cause the compiler to compile a different bank of source code.

On top of the operating system layer are the main guts of FileFlex and that is common across not only all operating systems but all development environments of which today we support a moderate amount and in the future I intend to support a much more significant amount.

The existence of all these development environments necessitated the creation of the third layer, the top layer of FileFlex: the Development Environment Interface Layer. This layer, too, has to change with the different development environments, especially since FileFlex must live inside them. Virtually every environment has its external API interface that must be supported.

Every one of these software development environments will have a different plug-in interface, and FileFlex had to be rearchitected in some way that supporting different interfaces did not require a vast rewrite of the product. Otherwise, it just wasn't going to happen. So, the Development Environment Interface Layer was created to do some degree of standardization between each of these development interfaces. This, too, was controlled by #ifdefs, allowing each interface to be created at compile time without incurring a performance or resource allocation hit during runtime.

Common FileFlex API

Another fundamental decision was to require FileFlex to have a common API in any development environment in which it was used. It struck me as worthless if you learn to use FileFlex in Authorware and then you moved to Director and you had to learn a whole new set of commands. Or if you moved from Director on the Mac to Director under Windows and the commands behaved differently. ach environment may call its externals in a slightly different manner. Obviously, Authorware (which is a visual programming environment) will call its externals in a manner substantially different from the way Lingo calls its externals.

In any case, if you know FileFlex's commands, calling conventions, and syntax in one environment, you will know them for all across all platforms. This is particularly important in the case of cross-platform development environments like Director. An absolutely essential development goal was that you could move projects from Director on the Macintosh to Director on Windows and vice versa, without having to rewrite all your code. There are obviously some exceptions. There are some minor exceptions for text handling and there are, of course, exceptions for file path handling. So, for example, you would separate items in a path with colons on a Macintosh and with backslashes under Windows. However, those changes are minor compared to having to rewrite all of your functions when you move it over from Mac to Windows. The same architectural goal is true of any other cross platform development environment.

Common Data File Format

Another requirement was that the data file that you use in any given development environment can be used in any other given development environment without having to go through a translation process. That's why we use the DBF standard with FileFlex to begin with, because we want to make sure that we support an industry standard data file. And it makes no sense if you decide to migrate your application from Director to Authorware or from SuperCard to Director, that you need to do a massive conversion on your data file. Again, this is especially true in the case of going from Mac to Windows. I talked to numerous users who are building CD-ROMs, and they're building a hybrid CD-ROM where they'll have a Macintosh-executable and a Windows-executable, and two or three hundred megabytes of data files. The last thing they want to do is duplicate those data files simply to support a Windows format and a Mac format. We allow you to share the data file format between each platform that FileFlex will operate under. One caveat: this does not necessarily mean that you can access the same data file at exactly the same time from multiple platforms or from multiple processes. FileFlex does not currently support multi- user access, although that's certainly something that we're exploring for future releases.

Pretty Ambitions Goals

To summarize, I had some pretty ambitious goals for this port of FileFlex. One, I wanted to make sure that we used a common source code model so I wouldn't have to spend an enormous effort synchronizing lots and lots of source files. Two, we architecturally divided FileFlex up into 3 layers: the Virtual Operating System Layer, the FileFlex Layer, and the Development Environment Interface Layer. This modular structure allows us to tune FileFlex for each of the host environments it needs to operate under. Further, the modularity could have no cost in terms of performance or resources, and so we needed to develop a compile time environment that would allow that to happen. Three, the application programming environment from the point of view of developers using FileFlex had to be identical from platform to platform, so no extra learning curve needed to be incurred. Fourth, there had to be a commonality of source code across platforms. This is so if you write code in one development environment on the Macintosh, you can move it to an identical development environment under Windows without having to rewrite all your code. And fifth, with the ability to use shared data files so that you didn't have to store twice the amount of data if you happened to want to build a hybrid CD.

The final requirement for FileFlex was that your decision to use it could not increase your overhead substantially. As a result, FileFlex consists of one single DLL or code resource file. When you distribute FileFlex to your customer, you only need to be concerned about moving that one file into a directory that you choose. FileFlex does not require you to have tons of files that need to be moved to lots of different directories in order to operate, as so many other Windows products do require. I consistently tried to make sure that FileFlex didn't turn into a pain in the butt.

Cross Platform Considerations

Today, FileFlex for Windows only runs inside of Macromedia Director. I have near term intentions to support both Authorware and SuperCard under Windows, but I have not yet completed these ports.

There is actually only one other significant cross platform consideration that you need to worry about other than your own personal religious operating system preferences. That concern is line termination in text and how it differs between operating systems. Briefly, the Macintosh terminates each line with a newline, and under Windows the convention is that each line is terminated with a carriage return and line feed. This doesn't become an issue in data storage in FileFlex except in memo fields which have hard carriage returns.

In fact, this actually isn't a consideration if you are moving data only inside of Director, because Director on both Macintosh and Windows uses the Macintosh format newline end of line character on both environments. As a result, if you write something that you store into a memo field in FileFlex on the Macintosh and you move it over to Windows and you run it in Director under Windows with FileFlex for Windows you will be able to read that memo field with no discernible difference.

The place where there is some concern is bringing in externally created DBF data files. This would happen, for example, if you created a data file in FoxPro under Windows and in the memo field had a number of carriage returns that were hard typed into the memo field. When you read that data in FileFlex and you moved it into Director, Director would have some ugly characters dropped into place, because Director would be looking for Mac formatted text data and FileFlex would have delivered the PC formatted data instead. Obviously, the same is true if you take data that you store in FileFlex that you want to read in FoxPro, FoxPro would get confused because it would have new lines, but not carriage returns.

To get around this problem, FileFlex, both on the Macintosh and in Windows, has a data file function called DBConvertCRLF. The purpose of DBConvertCRLF is to take a chunk of Macintosh text and convert it to a format that external Windows environment tools would expect, or take a chunk that comes from an external Windows format tool, and convert it to a form that would be suitable for use in the Macintosh. This applies to users who aren't even doing cross platform development, but who simply want to read PC data files that have memo fields. Now you can read a PC format data file with the memo field. You can read that data into a variable, you can run it through DBConvertCRLF, and out the other end will come a memo field that you can be comfortable displaying in a field on either a HyperCard stack or a Director project or whatever. Then, you can go the reverse. You can make your changes and you can send it back through DBConvertCRLF and store it back out to a file so that PC users can understand it without needing weird conversions.

FileFlex/ODBC Gateway

Component Software Corporation recently announced the acquisition of the Solis ODBC gateway from Solis Development, Inc. Renamed the FileFlex/ODBC Gateway, the new product provides a connection between Macromedia's multimedia authoring tools Director and Authorware and enterprise-class database systems like Oracle, Sybase, and Informix. The FileFlex/ODBC Gateway is a separate product from FileFlex. Usually they will not be used together.

FileFlex itself is a relational database engine that reads and writes dBASE III format .DBF files. By setting a compatibility mode in FoxPro, you'll be able to directly read data within FileFlex (which itself is an extension that adds features to Director).

Advantages are access to the same data that FoxPro reads with a minimal overhead in terms of drivers. Disadvantages are that Director and FoxPro can not have the data file open at the same time and that FileFlex does not provide multi-user access. FileFlex also doesn't handle the pure FoxPro format files. Another advantage is that runtime distribution of the FileFlex components are pretty inexpensive.

The FileFlex/ODBC Gateway adds Open Database Connectivity (ODBC) functionality to Director and Authorware. But you also need to have the ODBC drivers (standard under Windows, additional cost for Mac from a company called InterSolv). Because of the drivers and all the additional software, RAM requirements and system overhead are considerably more than the straight FileFlex solution. The FileFlex/ODBC Gateway allows multi-user access, allows (assuming your driver talks it) you to talk to many different databases in their optimized file formats, and also lets you talk to other database formats. But the cost structure is such that you're probably not going to distribute a solution using the FileFlex/ODBC Gateway for consumer CD-ROMS.

FileFlex is a great CD-ROM/kiosk solution. The FileFlex/ODBC Gateway is more of an enterprise oriented solution for access to large corporate databases.

"Component's FileFlex embedded relational database has given our multimedia developers the ability to embed standalone database functionality within their CD-ROM and kiosk development projects," said Joe Dunn, Macromedia's vice president of product management. "Component's acquisition of the ODBC technology now makes it possible for highly interactive multimedia productions to exchange information with databases throughout the entire corporation."

The new FileFlex/ODBC Gateway is a very important link in the chain connecting multimedia content to corporate information warehouses. The FileFlex/ODBC Gateway makes Director and Authorware ODBC-compliant. This means that projects built in these multimedia authoring tools can share information via SQL with corporate databases Sybase, Oracle, and Informix as well as PC-level databases like FoxPro, dBase, and Clipper.

Taken together, FileFlex and the FileFlex/ODBC Gateway provide a full range of embedded database solutions. FileFlex itself is a complete, self-contained database engine. It reads and writes the dBASE III/xBASE/DBF database format and is ideally suited for self-contained projects like CD-ROMs and kiosks. Many widely available commercial CD-ROMs use FileFlex behind the scenes to manage data.

By contrast, the FileFlex/ODBC Gateway provides access to databases anywhere in the corporation. A typical enterprise-wide multimedia database system using ODBC requires the multimedia tool (i.e., Director or Authorware), the FileFlex/ODBC Gateway, one or more ODBC drivers, and a corporate database engine like Sybase or Oracle.

Both FileFlex and the FileFlex/ODBC Gateway are available for Windows and Macintosh. Component Software's FileFlex database engine and the former Solis product are the two primary products providing database functionality across platforms and within Macromedia's authoring environments. This acquisition makes Component the leading supplier of embedded database solutions for multimedia productions. Feel free to contact Component or check our web site at www.component-net.com to get the latest information on the FileFlex/ODBC Gateway. 


  [Previous Chapter]    [Table of Contents]    [Next Chapter]
Copyright (c) 1996 David Gewirtz under license to Component Software Corp. All rights reserved worldwide.