Advantage Database Server Versus Advantage Local Server

In addition to ADS, Extended Systems also provides a database engine called the Advantage Local Server (ALS). ALS is very similar to Microsoft’s Jet Engine, which is used by MS Access, and Borland’s BDE (Borland Database Engine) when the BDE is using local tables. All of these database engines are file server database engines.

Unlike a database server, which is a stand-alone application, a database engine is essentially a library of data access routines that runs in the same process as the client application. Each client application will load its own copy of these database engine files, and each client application is responsible for all data manipulation.

Extended Systems makes ALS available to developers free of charge. Developers can use ALS with their stand-alone and small, multiuser applications, and can even distribute these applications to their clients without paying any royalty fees. The only applications that you are prohibited from using ALS with are those applications that run on the Internet, such as CGI (common gateway interface) Web server extensions. For those types of applications, you must use ADS.

Why, you are probably wondering, should you use ADS if you can use ALS for free? The answer is straightforward. ADS is better.

Actually, the benefits of a database server like ADS over database engines like ALS are associated with four factors. These are reduced network traffic, improved performance, enabled transactions, and unparalleled stability. Each of these factors is examined in the following sections.

Reducing Network Traffic

In short, the Advantage Local Server is not a database server, in the true client/server sense. With file server–based systems, all data processing is performed on the individual workstations. For example, to select all records from a customer table for customers in a particular city, the entire customer table index must be transferred across the network to the workstation, which then finds the record based on the index locally. The located records are then retrieved from the file server.

The problem is worse if an appropriate index does not exist for the table. In that case, the entire table must be transmitted across the network.

While this overhead is negligible if the customer table includes several dozen records, the strain that it places on the network increases with the size of the table. For example, selecting the hundred or so records for customers from Des Moines, Iowa, from a million record table requires that the entire index for all one million records be transmitted across the network.

The problem is particularly bad when you consider that the network load increases in direct proportion to the number of people who are using the application simultaneously. Every single client needs to read indexes and tables across the network in order to get its work done.

By comparison, Advantage Database Server performs its processing on the database server, which is typically the machine on which the shared data files are located. There is no need to copy entire indexes or tables across the network when the client application is interested in only a few records. Specifically, in a client/server environment, the client requests the records that it needs, and the server uses the indexes and tables to locate the needed data. Once the data is identified, that data, and only that data, is transmitted across the network to the client.

Improved Performance

Performance is another area where file server–based systems suffer. Specifically, the individual workstations are responsible for all processing. In other words, all user interface interaction as well as database manipulation is performed on each client workstation in a file server–based system. The file server itself performs no processing, other than transferring files from the server to the workstation.

By comparison, client/server systems perform nearly all data manipulation on the database server, efficiently distributing the processing across multiple machines. When using ADS, your workstations are primarily responsible for the user interface, while the remote server takes care of data manipulation.

Most database applications are multiuser, and it is in these situations where the performance advantages of the client/server architecture are most profound. However, note that in stand-alone applications, where the data is used by only one workstation, ALS-based applications might actually outperform client/server applications. In short, if the data is used by only one workstation, and the data is stored on that workstation, ALS often provides the greatest level of performance. For these applications, ADS provides you with a seamless, high-performance migration path when these applications are converted to multiuser use.

Available Transactions

A transaction is an operation that treats two or more changes to a database as a discrete unit, saving those changes in an all-or-none fashion. If all of the operations involved in the transaction can be completed, the transaction itself is committed. However, if even one operation cannot be successfully completed, all operations within the transaction are canceled, ensuring that your data remains consistent.

Transactions require centralized control of data access, and file server–based systems cannot provide that. Every change in a file server–based system is independent of every other change. As a result, it is entirely possible for a file server–based system to complete some, but not all, operations.

One very important feature of a transaction comes into play if the database server, the client workstation, or the network across which they communicate, fails before the transaction is committed. In those cases, the edits of the transaction are rolled back automatically by the Advantage Database Server once the problem is detected, or the server is restarted (if the server crashed).

Though ALS does not support transactions, you can write your applications that use ALS as if it did. Specifically, when using ALS, your code can include calls to begin, commit, and roll back transactions. These statements will be ignored. However, if you then migrate that application to use ADS, no changes are necessary in your code, and the transactions will be observed.

Improved Stability

The final drawback to file server–based systems is stability. Because there is no centralized control over locking and transactions, the failure of a single workstation can corrupt parts of the database. Developers familiar with BDE-based local table applications occasionally encounter errors such as corrupt or out-of-date indexes.

The issue of stability disappears almost completely when the Advantage Database Server is involved. In these applications, ADS itself is managing the data, and failure of an individual workstation or the network simply cannot harm the data.

When to Use the Advantage Local Server

If ADS is so much better than a database engine solution like ALS, why does Extended Systems bother making ALS available? Well, There are several, but they are all related to a simple fact. Not all applications require the benefits of ADS.

Imagine that you have written a database application that you plan on licensing to many different clients. Your software is probably pretty expensive, and pricing may be an issue for some of your customers. For example, consider a customer who will have only one or two users on the system. The additional cost of an ADS license may make the difference between selling the software or not. For those customers, you can deploy the application using ALS.

Imagine this same customer at some later time. Maybe they now have four simultaneous users, and they cannot tolerate the occasional corruption of an index due to a workstation crash. For a relatively small amount of money, you can upgrade their application to use the Advantage Database Server, and your customer can say “goodbye” to corrupt indexes.

For other customers, especially those who have a large number of users, there is no question about it—you will deploy their applications using ADS.

What is so great about this scenario is that there is no difference, from a development standpoint, between your application using ALS or ADS. The API (application programming interface) for ALS and ADS is exactly the same. And most of the time, upgrading an ALS application to use ADS is simply a matter of installing the server (a process that can be automated).

To put this another way, whether an application uses ALS or ADS is a deployment issue, not a development issue. You will write your application the same way regardless of which deployment option you choose.

Actually, there are a couple of differences, but they really serve more to underscore how similar the two interfaces are. As you have already learned, you can write your application to employ transactions, but only when you deploy with ADS will those statements actually do something.

There is another difference. If you are using the Java language and want to use the Advantage JDBC (Java database connectivity) Driver, you can only use ADS. This is because the Advantage JDBC Driver is a class 4 driver, which is to say that it communicates directly with the server, without going through a client API. If you want to use Java with ALS, you must use the JDBC-ODBC bridge (a class 1 driver), in conjunction with the Advantage ODBC (open database connectivity) Driver.

The second difference is related to triggers and extended stored procedures. With ADS, both triggers and stored procedures execute on the server. Since ALS is not a remote database server, any triggers or stored procedures will actually execute on the client workstation, so you lose the major benefits of distributed computing and reduced network traffic.

The bottom line is that ALS is a wonderful option for database developers. It provides you with a low-cost deployment option that effortlessly scales to client/server when client/server features are required.

Throughout this book we will assume that you are going to deploy your applications using ADS. But we will try to point out when a feature we are describing works differently between ADS and ALS.