Chapter 1: Introduction to Advantage Database Server

This chapter is designed to provide you with an overall picture of the Advantage Database Server (ADS), including what makes it special, a quick tour of the tools that you will likely use with it, as well as how to build database applications using ADS. If you are new to ADS, you will want to read this chapter carefully. Doing so will show you how you can use ADS in your database applications.

If you are already familiar with ADS, you probably already know much of what is discussed in this chapter. In that case, you might want to quickly skim this chapter before continuing on to Chapter 2. In particular, you might want to read the section “Features Added in ADS Version 7,” the latest release of ADS at the time of this writing.

Overview of Advantage Database Server

Advantage Database Server (ADS) is a relational database management system (RDBMS) marketed by Extended Systems, Inc., a company based in Boise, Idaho. ADS has been around since 1993, when it was introduced to provide a stable solution for Clipper developers who were tired of slow performance and corrupt indexes inherent to file server–based databases. Over the years, ADS has grown in both popularity and features. With the release of Advantage Database Server version 7.0, ADS finds itself a mature product with an impressive collection of features that rivals many of the more expensive and complicated database servers.

But what exactly is ADS? In a nutshell, the Advantage Database Server is a high-performance, low-maintenance, remote database server that permits you to easily build and deploy client/server applications. A lot of information is in that description, but what does it all mean? The following sections consider each of the points in this description.

ADS Is High Performance

First of all, ADS is a high-performance server. It permits you to manage very large quantities of data, and to access that data in a multiuser environment with unbelievable speed. For example, so long as you have designed your tables and indexes correctly, you can usually locate a particular record or subset of records in your database in a fraction of a second.

ADS’s performance derives from its underlying architecture. Unlike many of the more complicated and expensive database servers, such as Microsoft’s SQL Server and Oracle, ADS is not a traditional set-based relational database server based on SQL (structured query language). Instead, ADS is an ISAM (indexed sequential access method) relational database server. ISAM databases use indexes extensively, permitting them to perform high-speed table searches, filtering, and table joins.

Even though it is an ISAM server, ADS provides extensive support for the SQL language. Indeed, with ADS you can use the industry standard SQL language to perform almost any task related to the management of your data. When it comes to data access, these SQL statements are translated by ADS into optimized, index-based operations, providing you with an unbeatable combination of speed and accessibility.

The ISAM architecture has a long history. It is the same architecture that is used by venerable databases such as dBase, FoxPro, and Clipper. However, those databases were file server databases, while ADS is a client/server database server. In other words, ADS provides the unbeatable combination of proven performance and client/server reliability.

Unlike traditional ISAM databases, however, ADS supports many of the features that you find in high-end, set-based SQL database servers. For example, ADS supports views, stored procedures, triggers, referential integrity, and domain integrity constraints.

Note

Extended Systems also has an Advantage Replication server, a separate product from ADS, for companies who need to keep multiple databases synchronized. Information about this replication server can be found at www.AdvantageDatabase.com.

Another performance-related ISAM feature distinguishes ADS from set-based SQL databases. ISAM databases support a navigational model of data access, whereas set-based SQL databases do not. In the set-based database model, in theory at least, there is no record order. As a result, the SQL language does not support the concept of navigating a database. While some set-based SQL databases know that record B follows record A, the only way to move to a record that is 100 records after record A is to retrieve the record that follows A, then retrieve the record that follows that one, and again, and again, until this task is performed 100 times. Consider the Delphi language, which supports a navigational model of data access, a legacy of the BDE (Borland Database Engine). Imagine that a Delphi DBGrid (a grid-like component used for displaying a result set) displays data from a SELECT * FROM CUSTOMER query against a set-based SQL server where the CUSTOMER table contains a million records. If the end user presses CTRL-END while the DBGrid displaying this result set is active, the DBGrid will navigate to the last record—but in order to do so, it must fetch every single record. Anyone who has seen this knows that it will take a very, very long time before the user arrives at the last record. Furthermore, both the server and the network will be kept busy by this operation.

By comparison, records in an ISAM database have a record order, based on a selected index. If you point a Delphi DBGrid to an ADS table with a million records, and press CTRL-END, you will move immediately to the last record. This is because ADS can use the current index or the table’s natural order to go to the last record, and then return only those last records needed to fill the display of the DBGrid.

This is an important point, especially if you are coming to ADS from a file server database, such as Paradox, dBase, or Access. File server databases permit a navigational approach. If you want to migrate one of these databases to a set-based SQL database server, unless your database is very small, you will likely have to reprogram your user interface to remove any navigational features. Otherwise, users’ attempts to navigate can have serious consequences for your application’s performance.

The problem is that end users love the navigational interface. Having a grid that displays some records from a table, and having the impression that they can easily jump to somewhere in the middle of that table (or anywhere in the table they want to) is very appealing to end users. With ADS, you can provide that feature, but with set-based SQL servers, you should not.

Here is another way to look at it. With ADS you have a choice. You can write your applications using the portable and more or less standardized SQL language, or you can use a navigational model, or you can use both. With SQL-based remote database servers, you are limited to the set-oriented SQL language.

A number of the Advantage data access mechanisms permit you to build client applications that use the navigation model. These include the Advantage TDataSet Descendant, which can be used by Borland’s Delphi, Kylix, and C++Builder, as well as languages that can make direct calls to the Advantage Client Engine, which include Borland’s products as well as Microsoft’s Visual Basic and Visual C++.

Note

Development environments that can use ADO (Active X data objects) can leverage most of the navigational model through the Advantage OLE DB Provider. What is missing with ADO is that you cannot set ranges.

ADS Is Low Maintenance

Most database servers require a database administrator to keep them running smoothly and efficiently. And database administrators often require advanced training and certification. But with ADS, most applications require little or no maintenance. In most cases, once the ADS server is installed, you can pretty much forget about it, other than ensuring that your data gets backed up regularly.

“How can this be?” you ask. Once again, this is largely due to the underlying architecture of ADS. For example, so long as you use the Advantage proprietary format for your data tables, space previously occupied by deleted records is automatically recovered when new records are added. Similarly, ADS’s legendary stability makes it unnecessary to rebuild indexes, in most cases.

That ADS-based databases require little or no maintenance makes this server particularly attractive for applications that are distributed to many different locations. For example, if you license your application to many different clients, the less you or they have to worry about managing the database server, the better. This is why ADS is a good choice for vertical market applications and for applications that are deployed to many different systems.

ADS Is a Remote Database Server

A remote database server like ADS is an application specifically designed to provide other applications with access to one or more databases. Those other applications are referred to as clients, and most client applications are end user applications. This configuration, where clients request data from a remote server, is referred to as client/server architecture.

The client/server architecture offers many advantages, but the most important is reliability. With ADS, you have confidence that your data is secure and accessible.