I have considered myself a database developer since Loy Anderson and I launched our business in 1988. During that time, I have had the pleasure of working on a large number of different and exciting database projects in almost every field imaginable, from medical to legal, from financial to aerospace, from manufacturing to distribution.
I also started training corporate software developers in 1988, and in the intervening years have trained thousands of database developers. In the early days, most of these developers used a local, file server–based database engine, such as Paradox, dBase, FoxPro, Clipper, or MS Access, though over time an increasingly greater proportion used a client/server architecture. But even to this day there are a surprisingly large number of developers still using a local database engine.
Over the years, as the limitations of the file server–based architecture became more widely understood, a specific interaction repeated itself over and over, and does so to this day. A developer in one of my seminars will approach me during a break and relate that they are still using a local database engine. Realizing that they need greater stability and performance, they will tell me that they are switching to a particular database server, almost always one of the big-name database servers. When I ask them how many users are on their system, they often reply that they have three or five or ten. Rarely more than twenty.
This exchange always leaves me feeling a little shocked. Do they know what they are getting themselves into? Sure, the client/server architecture offers greater stability and increased performance, but are they going to be able to allocate the resources that most of the high-end database servers require? Do they have a DBA (database administrator) already? If not, can they afford to hire a DBA? Can they afford the continuing training and certification? Is the expense worth it when they have only five users?
I’m sharing this background with you so that you will understand why I am such a huge fan of Advantage Database Server (ADS). For almost every developer with whom I have had the preceding interaction, ADS is a better solution for implementing their application using a client/server architecture, one that can easily handle hundreds of users. Not only does ADS offer the reliability and performance of a remote database server, it does so with a very minimum of administration. In a world where we often confuse sophistication with complexity, ADS is the perfect exception to the rule. But isn’t this the way it should be? Simple sophistication. Wouldn’t it be great if all software were like this?
But there is something else about the Advantage Database Server that originally attracted my attention—the company that makes it. From my very first contacts with the Advantage group at Extended Systems, all the way through the writing of this book, I have been continuously impressed with the level of professionalism and commitment by the people behind the product. From the individuals in marketing and sales, through the management and development team, there is a culture of pride that permeates this group. Ask anyone who uses ADS and you’ll likely hear the same thing. This product is great, and so is the company behind it. What a combination.
Don’t get me wrong: My admiration for the people behind ADS is not intended as a slight to other software companies. Indeed, I have had in the past, and continue to have, great respect for a number of the software companies that I deal with, the people who work at them, and an appreciation for the culture of excellence that they engender. Borland Software Corporation is an outstanding example of what I am talking about. But the fact remains that ADS is backed by a first-rate company that respects and supports its customers. You can't say that about every software company.
This book is designed to get you started using the Advantage Database Server, organized into three parts. In Part I, you learn how ADS gives you the performance of a world-class, relational, remote database server without the complexity normally associated with the client/server architecture. Topics discussed here include what ADS is, what your data access options are, how to build tables and indexes, and how to set up a data dictionary in order to create a secure and feature-rich database.
In Part II, you learn the ins and outs of Advantage SQL, the particular dialect of ANSI/92 SQL used by the Advantage Database Server. And in Part III, you learn how to access your ADS data from the most popular development environments, including Delphi, Java, Visual Basic, C#, and more.
The CD-ROM that accompanies this book includes code samples as well as a set of database files. As you progress through the chapters of Part I, you will make modifications to this database, adding tables, indexes, a data dictionary, constraints, stored procedures, triggers, and more. Each chapter contains step-by-step instructions that walk you through the process of creating these various objects. Consequently, in most cases, you will want to start this book from the beginning and work your way through the chapters in sequence.
There is one thing to note about this database that you will be working with in this book: The examples described do not add all of the objects that you would probably want to add to this database if you were creating a production application. For example, the step-by-step instructions only have you add the indexes that are necessary for the other objects you will create later in the book, such as referential integrity definitions.
In other words, if you were actually going to deploy this database, you would likely add many more indexes than we have you add here. But that point, and other similar points related to the creation of objects, is made repeatedly throughout. For a real database, you create those objects that support the features that you want to implement in your client applications. Importantly, the chapters in Part I explain what these features are and show you how to define them.