to a discussion of various conventions that I use when programming databases. Next, I discuss key database tools that ship with BCB, and close with a discussion of getting ODBC and TCP/IP set up on your system.

In subsequent chapters I move on to a discussion of advanced client/server issues. I am covering such basic material as you find in this chapter in a book on intermediate-to-advanced programming because there are so many C++ programmers who are new to the database world. If you have much experience in C++ desktop and systems programming, but little database experience, you should take the time to work through this chapter. BCB makes this subject easy to master, and once you have database tools at your fingertips, you will be surprised how many uses you can find for them. This is especially true in the data-centric, Internet-based world most programmers live in these days.

More advanced database programmers should also read this chapter, because I include an overview of the BCB database architecture. All serious developers need to be concerned with matters covered in this chapter such as Object Repositories, business rules, the proper use of TDataModule, and so on.

More specifically, the subjects covered in this chapter include introductions to the following:

• The TTable, TQuery, and TDataSource objects. The discussion of these subjects will show you how to connect to tables with and without SQL.

  　

• The tools available for creating aliases.

  　

• The Object Repository, Database Explorer, and SQL Monitor.

  　

• The TDataModule keeps your form clear of database objects, and it consolidates your database code and rules in a single object that can be shared in multiple applications. In particular, it enables you to place nonvisual components, and particularly nonvisual database components, on a special window that remains hidden at runtime. This window can be stored in the Object Repository and can be used to specify business rules that can be reused by a wide range of projects and programmers.

  　

• The last part of this chapter covers the different means for accessing data from inside BCB. For instance, you can use the BDE, ODBC, and SQL Links. In this section you learn about the difference between Paradox, dBASE, InterBase, Oracle, and Sybase, as well as other related matters.

  　

• The chapter ends with a discussion of using ODBC, and of setting up TCP/IP on your system.

After you have covered the basics in this chapter, the next step is to move onto the in-depth discussions of these topics found in the next few chapters. In particular, the next chapter covers the TTable object in depth, and the following chapter covers the SQL-based TQuery object.

Here is an overview of what lies ahead:

• Chapter 8: This chapter, which covers database basics, including introductions to TTable and TQuery

  　

• Chapter 9: An in-depth look at TTable and TDataSet

  　

• Chapter 10: An in-depth look atTQuery and an introduction to SQL programming

Subsequent chapters in this section of the book cover intermediate and advanced database topics. For instance, you will find more material on the database tools in general and on CASE tools in particular, in Chapters 17 and 18.

The logic behind arranging things this way is to enable you to first get an introduction to BCB and databases, and to then dig into the subject once you understand the issues involved. This way I can keep the simplest subject matter out of the latter chapters so they can focus on relatively serious programming issues.

If you are interested primarily in design issues, you can safely skim through this chapter, looking only for the parts that interest you. If you have not built a BCB database program before, you should read this entire chapter through from beginning to end.

On Setting Up the Database Tools

BCB comes ready to run Paradox, dBASE, and local InterBase tables. If you have the client/server version of the product, it comes with the full InterBase server. The client/server product also lets you access any DB2, Informix, MS SQL Server, Sybase, and Oracle you have available. The very first version of BCB does not ship with built-in support for Access or FoxPro, but if you have Delphi 3.0 installed on your system, you can get access to these features automatically.

　

---

NOTE: The issue here is that BCB 1.0 ships with an older version of the BDE than Delphi 3.0, because the new version of the BDE was not available at BCB ship time. If you can get the most recent version of the BDE, BCB will work with it automatically, which means you can get at Access tables. You can sometimes download the BDE directly from the Borland Web site at www.borland.com. If you can't get the most recent version of the BDE, you can use ODBC to, as they say, access "Access."

It does not matter that BCB shipped with an earlier version of the BDE than the one you may be running on your system. The BDE was designed to handle this type of situation, and it is entirely regular. I use the most recent version of the BDE with my copy of BCB, and I never have any hint of trouble.

---

　

The primary way to access data from BCB involves the BDE, or Borland Database Engine. This engine, which is explained in more depth near the end of this chapter, is the backbone of the BCB database tools.

Paradox, dBASE, and Access tables can be reached directly from the BDE. To access the other databases, you also need SQL Links, which is a product that ships with the client/server version of Delphi.

One simple way to find out what database access you have from your system involves dropping down a TDatabase object on a form and examining its DriverName property in the Object Inspector. This property contains a list of the installed drivers on your system. For instance, all the databases listed earlier in this section appear in this Property Editor on my system. (Paradox and dBASE tables are accessed through the driver labeled "Standard.")

If you are having trouble accessing some or all databases from your system, the best remedy is usually to do a complete uninstall and a complete reinstall. The local database systems ought to work automatically out of the box without any effort on your part. For instance, I have probably installed BCB 50 times on a variety of systems, and I have always been able to reach Paradox or dBASE tables immediately after installation.

Users of the BDE should be aware that BCB ships with a tool called the BDE Configuration utility. This application can be accessed from the Start menu. You can use this tool to make sure the BDE itself is running correctly. As a rule, if the BDE is not running, you will not be able to access databases from inside of BCB.

Database Basics

To create a simple database application, start by placing a TTable, a TDataSource, and a TDBGrid component on a form, as shown in Figure 8.1.

FIGURE 8.1. TTable, TDataSource, and TDBGrid arranged on a form.

Wire these three controls together by completing the following simple steps:

1. Connect the DataSource property of the TDBGrid to DataSource1.

2. Connect the DataSet property of the TDataSource control to Table1.

After completion of these steps, the three components are hooked together and can communicate with one another.

Connecting the TTable object to a table that resides on disk is a three-step process:

1. Set the DatabaseName property either to a valid alias or, in the case of Paradox or dBASE, to the subdirectory where your data resides. For the example currently under discussion, you can set the DatabaseName property to the BCDEMOS alias, which is created by default during BCB's installation. Alternatively, you could type c:\CBuilder\demos\data into the DatabaseName Property Editor, where you might need to change some aspects of this path depending on where you choose to install BCB.

2. Set the TableName property to the name of the table you want to view; for instance, you might choose the CUSTOMER.DB table. The Property Editor drops down a list of available tables, so there is no need for you to type anything; the whole job can be done with the mouse.

3. Set the Active property, found at the very top of the Object Inspector, to true.

When you are done, the Object Inspector should look as it does in Figure 8.2.

FIGURE 8.2. The Object Inspector after connecting to a table called Customer, using an alias called BCDEMOS.

If you have completed all these steps properly, you should now be looking at the data from the table you chose, as shown in Figure 8.3. To take this process one step further, you can compile and run the program and then begin browsing and editing your data.

FIGURE 8.3. Simple form displaying the contents of CUSTOMER.DB.

If you want to simplify the task of browsing through the data in your application, you can go back into design mode and add the TDBNavigator control to the program. To hook this control into the loop, all you need to do is set its DataSource property to DataSource1. Now you can run the program and begin iterating through the records with the navigator, as shown in Figure 8.4. In Figure 8.4, most of the functionality of the TDBNavigator has been turned off by manipulating its VisibleButtons property. For instance, a navigator can automatically enable you to edit, insert, delete, post, cancel, and refresh. All those capabilities have been disabled and hidden in the form shown here by manipulating the VisibleButtons property of TDBNavigator.

FIGURE 8.4. A simple database program with a TDBNavigator control.

A program like the one described here is found on the CD-ROM that accompanies this book as Simple.cpp. Programs like this are the bread and butter of the database world. You might even find it useful to create several programs of this type, just be to be sure you can do it quickly and easily with little thought. BCB database programmers work with the TTable, TDataSource, and TDBGrid objects on a regular basis, and the basics of their operation should be as easy as tying your shoe.

Naming and Architectural Conventions

In this section I lay out a number of conventions that I generally abide by in

programming projects. Before beginning, I should emphasize that these are merely conventions. There are no hard and fast rules in this area, and you should feel free to follow my suggestions only to the degree that they suit your taste. In fact, you

will find that I myself do not follow these conventions one hundred percent of the time, though I generally conform to them when I am not feeling too rushed. I also have included legacy code in this book in which I did not adopt the techniques that I currently believe are best. In some cases, I have updated the legacy code, but some sample programs still use old conventions.

When arranging tables on a data module, I usually follow some simple naming conventions. If I attach a TTable object to a table called Customer, I will call the TTable object CustomerTable. The data source attached to that table will generally be called CustomerSource.

　

---

NOTE: An alternative technique, called Hungarian notation, would name all TTable objects tblXXX, where the XXX is the name of the table you want to use: tblCustomer, tblBioLife, and so on. You could then prefix ds before the table name to designate the name of the data source: dsCustomer, dsBioLife, and so on. This was the technique I used in the past, but which I no longer believe to be best.

The Hungarian system enables you to automatically group all the objects shown in the Object Inspector according to type. If all the tables begin with tbl, they will appear together in the Object Inspector.

Despite this advantage, I have decided against Hungarian notation on the grounds that it tends to make even simple code appear a bit abstruse. Recondite code has a certain emotional appeal, but it is not the effect I want to strive for in a book that champions the virtues of clear, easy-to-read logic.

In general, I try to avoid systems that force me to use hard to read abbreviations, or that clutter up the beginnings of words. In particular, I find an identifier like dsCustomer unpleasant because it makes the type of the variable appear more important than the name of the variable. This system also makes it hard to read the identifier, because you have to mentally skip over the first syllable before getting to the key piece of information contained in the name. Of course, my least favorite naming convention abbreviates both the type and the variable name:

　

DDSURFACEDESC ddsd;

HBITMAP hbm;

RGBQUAD * prgb;

Incredibly, these samples are taken from source code distributed by a major software company in order to promote a new API. I am at least tempted to believe that the people who came up with these variable names were trying to be funny, or perhaps just to pull someone's leg. At any rate, these are classic examples of naming conventions that I try to avoid.

So, in this book, it will generally be CustomerTable, and not tblCustomer. If you prefer some other system, you should feel free to pursue your tastes. After all, many of the best programmers use Hungarian notation on a regular basis. In fact, in the world of C++, my tastes probably represent a minority opinion.

---

　

In simple projects that have only one data module, I will usually call the files associated with the data module DMod1.cpp and DMod1.h. The TDataModule object itself I usually rename to TDMod. In more complex projects that have multiple data modules I might rename the data module to something more meaningful such as TDModAddress, and I might then save the file under the name DModAddress1.cpp.

Please note that my convention is to name the file in which a data module or form is stored as the same name as the data module or form, except that I append a 1 to it. Thus the file in which a data module called TDMod is stored will be called DMod1. This prevents name conflicts between the object name and the filename. If I have a form called TAddress, I will save it in a file called Address1.cpp. The one exception to the previous rule is that I tend to name the main module of a project Main.cpp, and I then usually keep the main form default name of Form1.

Please understand that I have included this section more as a courtesy than out of a desire to attempt to force my tastes on someone else. I want you to know and understand the conventions I use, but you should feel free to use the techniques that you feel work best.

Enough on naming conventions. It's time now to move on to a related, but slightly

different matter regarding the proper use of data modules.

Using the TQuery Object

You can create a BCB SQL statement by using a TQuery component in the following manner:

1. Drop down TQuery, TDataSource, and TDBGrid objects on a form and wire them together.

2. Assign an alias to the DatabaseName property of the TQuery object. For instance, use the BCDEMOS or DBDEMOS alias. These aliases are created automatically by BCB and Delphi, respectively, during installation.

3. Use the SQL property to enter a SQL statement such as Select * from Country.

4. Set the Active property to True. If you completed each step correctly, and if the BDE is set up correctly, the grid should now contain the records from the Country table.

If you're working with local data, you can substitute a fully qualified subdirectory path for an alias. When using the latter method, it's best if you don't include the actual name of a table, but only the subdirectory in which one or more tables exist.

In my opinion, however, it is almost always better to work with an alias rather than specify the path directly in the DatabaseName property.

That's all I'm going to say about TQuery for now. Later in this chapter I discuss the SQL monitor tool that comes with BCB. In subsequent chapters I begin using SQL statements more heavily. I find it easier to use TTable than TQuery for many basic database operations. However, as I discuss matters of increasing complexity throughout the database section of this book, I will rely more and more on SQL.

The Data Module

Earlier in this chapter, you placed a TTable and TDataSource

component on the same form with your visual components. When you ran the program, the icons representing these components disappeared. However, they are visible at design time and have a tendency to clutter up the form. Partially out of a desire to eliminate this clutter, BCB features a component called a TDataModule, which can be used to store nonvisual controls such as TTable and TDataSource. A program on disk called SimpleTable shows how to use the TDataModule component.

To get started working with TDataModules, first begin a new application. Next, choose File | New and select the Data Module component from the New page of the New Items dialog, as shown in Figure 8.5. You can also choose to create a data module directly from the New Data Module option on the File menu. You should, however, get used to using the Object Repository as it plays a big role in BCB programming.

FIGURE 8.5. Selecting the TDataModule component from the New Items dialog.

　

---

NOTE: A TDataModule is not the same thing as a form. For instance, if you look in its ancestry you will see that it is a direct descendant of TComponent. When you first see a TDataModule object, there is a tendency to view it as merely a special kind of form, which is, to some degree, true, at least in a very nontechnical sense. However, the hierarchy for a TForm component looks like this:

　

-TComponent

-TControl

-TWinControl

-TScrollingWinControl

-TForm

The hierarchy for a TDataModule, on the other hand, looks like this:

-TComponent

-TDataModule

Clearly, TForms and TDataModules are two very different beasts, despite some apparent similarities between them.

The header file that contains the declaration for the TDataModule class is FORMS.HPP. If you have the Pascal source to the VCL, the TDataModule object is found in FORMS.PAS.

---

　

After adding a TDataModule object to your application, take a moment to save your code. You might save Unit1 as MAIN.CPP and Unit2 as DMOD1.CPP. Click Form1, open the File menu, and choose the Include Unit Header expert from the menu. In the Include Unit dialog, select DMod1 and press OK. This is a simple way of automatically inserting an #include directive at the top of Unit1. In particular, the following changes are made to your code:

#include <vcl\vcl.h>

You can, of course, type in the #include directive without using the small expert found on the File menu. There is no particular advantage in using the expert other than its ease of use. Remember, however, that if you want to include a unit in your project, it is generally not enough to simply add a header file to a unit. You must also be sure the unit has been explicitly added to your project. In the case discussed here, there is no need to explicitly add Unit2 (a.k.a. DMod1) to the project, because it was done automatically when you first created the unit.

　

---

NOTE: This is a time when some programmers may need to force themselves to abandon the old "command-line" attitude, and to instead embrace a visual tool that can help make you more productive. As always, the choice is yours, but if the visual tools are easier to use, and if they make you more productive, you should consider using them. Command-line programming has an honorable place in this world, but it is generally not part of the attitude that makes for good RAD programmers.

Let me tack on one additional piece of information to this note. If you want to add a module to a project without using the project manager, and without editing a makefile, you can use the following syntax:

　

#pragma link "dmod1.obj"

This syntax can be very useful when adding components to the component palette. See the FTP2.cpp module in the Utils directory from the CD-ROM that ships with this book for an example of using this approach.

---

　

Arrange Form1 and DataModule2 on the screen so you can view them both at the same time. Drop a TTable and TDataSource component on the data module, as shown in Figure 8.6.

FIGURE 8.6. Form1 and DataModule2 arranged on the screen so that you can easily view them both at the same time.

　

---

NOTE: For various reasons I snapped my screen shots for this book at 640x480 resolution. Needless to say, I don't usually run BCB at that resolution. 1024x768 is probably a more reasonable size when working with an environment like this, though even higher resolutions would be better. 800x600 is tolerable, but I still feel the pinch when working at that low a resolution.

---

　

Wire the TDataSource to the TTable object, and set the DatabaseName of the TTable object to BCDEMOS and the TableName to BioLife. Set the Active property of the TTable object to True.

Right-click the TTable object and bring up the Fields Editor. Right-click the Fields Editor, and bring up the AddFields dialog. Make sure all the fields in the dialog are selected, which is the default behavior for the tool. Click the OK button.

The Fields Editor now contains a list of all the fields in the BioLife table. To add these fields to your form, simply click one or more fields, hold the left mouse button down, and drag the fields onto the form. For instance, select the Graphics field, making sure that it is the only one highlighted. Now drag it onto the form. When you let go of the left mouse button, the Graphics field will automatically display itself in a TDBImage component. Drag over several other fields, and create a form that looks something like the image in Figure 8.7.

FIGURE 8.7. Some of the fields of the BioLife table arranged in visual controls on a TForm object.

If you want to drag multiple fields over at the same time, perform a multiselect operation in the Fields Editor, just as you would in a list box. Now drag all the fields over to the main form at once. Most likely they will scroll on past the bottom of your form when you insert them, but you can fix this easily enough by aligning them as you like with the mouse.

The TDBImage component, where the picture of the fish is displayed, may be in some disarray when you first insert the components on the form. To straighten things out, select the TDBImage component, go to the Object Inspector, and set the Stretch property to True.

A sample program illustrating these principles ships on the CD-ROM that accompanies this book. It is called SimpleDataModule.

The Purpose of TDataModule

Now that you know how to use the TDataModule, let me add a few words on its significance. This component's primary purpose is to provide a place where

you can define the means for accessing a set of tables. However, it is also a place to put business rules, and a place to create reusable means of accessing data.

Client/server database programmers often want to put all the rules for accessing

data on the server side. Indeed, BCB supports this paradigm, and you can use stored procedures, views, and other advanced database technologies to whatever degree you want when accessing SQL databases. However, you also have the ability to define a

set of rules that live on the client side, inside a TDataModule. You can then use the Object Repository from the File | New menu choice to store this form in a place where it can be reused by multiple programmers. To put a form in the Object

Repository, right-click it and chose Add to Repository from the menu. I discuss the Object Repository in more depth later in this chapter.

There is no simple way to decide when it is best to put rules on the server side or when it is best to put them inside a TDataModule. Often the best solution is to use a combination of the two techniques. Put things on the server side when that is simplest, and store things on the client side when you think the power of C++ and its strong debuggers will be useful to you.

There is considerable complexity in the whole set of related subjects that involve designing databases, creating business rules, and creating metadata such as stored procedures on a server. Many of these topics will be explored in considerable depth in the next few chapters. However, a thorough examination of these topics requires considerably more scope than I have in this book.

Conventions Regarding the Use of TDataModules

When working with database code, I often prefer to put my TTable, TQuery, and TDatasource objects in a TDataModule, rather than placing them on a form. In other words, I think there are architectual reasons for using TDataModules rather than placing tables directly on a form.

There are several interrelated advantages to this scheme, most of which have to do with proper design issues. In particular, the scheme outlined previously enables me to do the following:

• Separate my database code and my GUI code. In an ideal situation, all the front-end code is in my form, and all the database code is in the TDataModule.

  　

• Protect the data in database code. It can sometimes be bad practice to directly access any of the methods or fields of an object from inside another object. Instead, you can present a series of public properties and methods as the interface for an object. There is, however, nothing wrong with accessing the properties of a TTable and TQuery object through pointer notation. In other words, the rules of aggregation state that it is acceptable and safe to write DMod->Table1, rather than trying to hide Table1 behind methods of TDMod that wrap the object and hide it from sight.

  　

• Promote reuse. By isolating the database code in the TDataModule, and by protecting the data associated with my database code, I am creating a robust object that can be reused in multiple programs. In particular, several programs may want to access data in the same manner. By using a TDataModule correctly, you can encapsulate your data, and its associated rules, inside a single related object that can be reused in multiple programs. This is one way to create a set of reusable business rules that can be shared by multiple members of your team, or by multiple programmers.

I will often use the constructor of a TDataModule or its OnCreate event to open up the tables or data modules used in a project:

void __fastcall TDModBioLife::DModBioLifeCreate(TObject *Sender)

This is the proper and ideal way to do things. I want to stress, however, that it is also correct from an OOP standpoint to access the same table from inside your main form through the scoping operator:

void __fastcall TForm1::Button1OnClick(Tobject *Sender)

You can use either technique, depending on your needs. Most of the time, you will use the second technique shown here, the one that uses scoping operators. There are, however, some good arguments in favor of using the first method. In particular, the first technique is pure from an OOP point of view in that it completely hides the details of what goes on in the TDMod object.

One problem with the rigorous technique illustrated by the first example is that it can add complexity to simple programs. If you only need to access one table, and only need one TDataSource object, even the simple act of creating a data module can seem like overkill. Going even further and insisting that the code for manipulating the table also reside in the TDataModule can then seem almost absurdly roundabout and abstruse.

In the type of simple database projects that you will see in this chapter, it is possible to forgo the use of data modules altogether and to instead place the TTable and TDataSource objects directly on your main form. However, I will generally use a TDataModule even in such simple cases simply because it is the best way to architect an application. The point is to get in the habit of doing things the right way, because ultimately, in large scale projects, decisions such as this do matter.

　

---

NOTE: Data modules can be used not only for data controls, but for all nonvisual controls. You can, for instance, place a TMenu object on a data module, and then add the data module's header file to your main form, thereby accessing the TMenu object through the Object Inspector. The problem with this technique, of course, is that the methods you want to access from the menu are not always going to be located in the data module. Another issue is that your form and the data module will then be bound together, at least to some degree.

---

　

Remember that one of the key features of data modules is that they provide a place to store a set of business rules. You can create tables and queries, link them together, and use code to define rules regarding the way they work. To replicate these rules in multiple projects, simply reuse the data module that contains them.

The Object Repository

In the last section, I said that data modules can help promote reuse of code. BCB has a specific mechanism called an Object Repository that can help with this process. In particular, Object Repositories are a place where you can store data modules and forms so that they can be reused in multiple applications. If you define a set of business rules in a data module, you can save it to the Object Repository and reuse it in multiple projects. This helps you propagate the rules and promote conformity to them across a wide range of projects.

The simplest way to introduce you to the Object Repository is to just lead you step-by-step through the process of using it. After you have seen how it works, I will take a moment to explain its significance.

Save the program you created in the last section as follows:

1. Save Unit1 as Main.cpp.

2. Save Unit2 as DModBiolife.cpp.

3. Save the project file as Biolifeapp.

4. Rename the table and data source to BioLifeTable and BioLifeSource.

5. Select the data module and use the Object Inspector to rename it from DataModule2 to DModBioLife.

Right-click the data module and select Add To Repository. Fill in the Add To Repository dialog by setting the Title, Description, and Author fields as you see fit. In the Page drop-down combo, select Data modules. Use the Browse button to select an icon from the ..BCB\images\icon subdirectory, or from any place else where you might have some icons stored.

Start a new project. Choose File | New. This time, instead of choosing the Data module component from the New page, select the Data modules page and choose the DModBioLife component that you just finished creating. When it appears on the screen, you will see that it contains a TTable and TDataSource component. The components are wired together, and the TTable object is set to the BioLife table with its Active property set to True.

To access this table from Form1, you must first employ the Include Unit Header menu option from the File menu to add Unit2 to the uses clause in Unit1. Go to the DataControls page of the Component Palette, and drop down a TDBGrid object on Form1. In the Object Inspector, drop down the DataSource property of the TDBGrid object, and you will see the TDataSource object from the DModBioLife module listed. Select this item, and the grid will automatically fill up with data.

If you drop down a TDBEdit control instead of a TDBGrid control, you proceed the same way, except that you will need to fill in not only the DataSource property in the Object Inspector, but also the DataField property. There is no need to type information into the DataField property, because it will

automatically contain a list of the available fields in the BioLife table.

The true significance of the Object Repository is only hinted at by this example. The importance of this tool is made more obvious if you have six or seven tables dropped onto a data module. You might then define several relationships between the tables and add other related code. For instance, you might have some one-to-many relationships established, possibly a many-to-many relationship established, and you might have several filters, lookups, and several calculated fields defined.

Altogether, a data module of this type might encapsulate several sets of business rules defining exactly how tables should be accessed and how they relate to each other. The ability to save all this work in the repository, and to then automatically reuse it in multiple projects, is extremely valuable. I am, however, getting ahead of myself. Discussions of filters, lookups, calculated fields, and other database issues occur in various places over the next few chapters.

The Database Explorer

In addition to the data module, another key tool to use when working with databases is the Database Explorer. You can access the Database Explorer by choosing the Database | Explore menu item. The Explorer is a stand-alone executable, so you can also access it from the Windows Start button on the taskbar. You can use the Explorer even if

BCB is not running, but BCB and the Explorer work best in conjunction with one another.

Once you have loaded the Explorer, make sure you have selected the Databases page and not the Dictionary page. Click the BCDEMOS node to expose the Tables node. Now click the little plus sign before the Tables node. A list of all the tables in the database will appear. Select the BioLife table and choose the Data page to view the contents of the table, as shown in Fig- ure 8.8.

FIGURE 8.8. Exploring the BioLife table in the Database Explorer.

Click the little plus symbol in front of the BioLife.db node, and you will see a list of properties for the BioLife table. The properties listed are Fields, Indices, Validity Checks, Referential Constraints, Security Specs, and Family Members. You can expand each of these nodes to view their properties. For instance, if you select the Fields node, you will see a list of all the fields in the table. As you select each individual field, you will see a description of its primary characteristics.

　

---

NOTE: The Database Explorer provides a means for viewing the text of stored procedures and triggers. You cannot edit these values, but you can view their code.

---

　

The Database Explorer is a fairly complex tool with a number of powerful traits, many of which will undoubtedly be expanded in future versions of the product. In particular, you should note that it contains a DataDictionary that enables you to define a new alias or modify existing aliases.

At this stage, I want to show you only one key trait of the Database Explorer. Arrange your screen so you can view both the Explorer and Form1 at the same time. Select the BioLife table in the Explorer with the mouse, and then drag and drop it onto Form1. If you want, you can experiment further by expanding the BioLife node in the Explorer and dragging and dropping individual fields of the table onto Form1, just as you did when using the Fields Editor.

If you start a new application, and then drag and drop the BioLife table onto Form1 from the Explorer, you will find that the TTable and TDataSource objects are placed on Form1. If you want to move them off the form, you can add a TDataModule object to the project, and then select both the TTable and TDataSource objects and choose Edit | Cut from the menu. Now select the TDataModule object and choose Edit | Paste. Make sure Form1 contains a reference (#include) to the unit that contains the TDataModule, and then hook up the grid to the TDataSource object in the TDataModule. This sounds like a fairly complicated process when written out, but you can perform this task in just a few seconds using BCB's visual tools.

Once again, the last few paragraphs have done nothing more than introduce you to the Database Explorer. This is a complex tool that will prove useful to you in many different ways, some of which might not even have been apparent to its creator. For now, the key point to grasp is that it gives you an overview of all the data in a database and enables you to drag and drop fields and tables onto your forms.

Working with the SQL Monitor

The SQL Monitor is an advanced tool that enables you to see exactly what SQL statements are being generated by your application when you are running queries against SQL databases such as InterBase. The SQL Monitor only works when you are using an ODBC connection or SQL links to access real databases such as InterBase, Oracle, Sybase, or Informix. In other words, it is not useful when you are using the TTable object, or when you are accessing Paradox or dBASE tables.

There is no trick to using the SQL Monitor. If it ships with your version of BCB, you can simply select the SQL monitor from the Database menu, run your program, and then browse through the SQL Monitor to see the specific statements generated by your program.

Here is code produced from a simple SQL request for all the rows from the Customer table from the IBLOCAL alias. Note that in this case I am using an InterBase table. InterBase is an ANSI 92 SQL-compatible database server:

1 18:49:40 SQL Prepare: INTRBASE - select * from Customer

All this information can be a bit overwhelming at times. To simplify the output from the SQL Monitor, select Options | Trace Options from the SQL Monitor menu. The dialog shown in Figure 8.9 is launched. You can then select just the first two, or perhaps only the second option. The output from the same test run previously then looks like this:

2 04:54:44 Log started for: Project1

Now you see only the prepare and execute statements, which is probably all the information you needed. A screen shot of the SQL Monitor with this simple information in it is shown in Figure 8.10.

Once again, the SQL Monitor is only for use with powerful databases such as InterBase or Oracle. I will present in-depth discussions of InterBase later in this section of the book.

FIGURE 8.9. The SQL Monitor Trace Options dialog is accessible from one of the program's speed buttons.

FIGURE 8.10. The SQL Monitor showing prepared and executed SQL statements.

Understanding the BDE and Aliases

The BDE is the Borland Database Engine, which used to be called IDAPI. This engine is the gateway to all the databases accessed from BCB, except under certain unusual circumstances.

The BDE gives you direct access to Paradox and dBASE tables. If you own a copy of Paradox or dBASE, you already have the BDE installed on your system. The brains behind these two products is the BDE. Paradox and dBASE are merely wrappers around the BDE, in much the same way that the BCB IDE is a wrapper around a C++ compiler.

Besides giving you access to Paradox and dBASE, the BDE also uses Borland's SQL Links technology to give you fast access to client/server databases. In particular, BCB ships with SQL Links drivers for InterBase, Oracle, Sybase, MS SQL Server, DB2, and Informix.

The list of available client/server databases changes depending on the version of the BDE you are using. To check the current list, open up the BDE Configuration application that ships with BCB and look at the available list of drivers. (See Figure 8.11.)

FIGURE 8.11.

The Borland Database Configuration utility (BDECFG32.exe) provides a list of available SQL Links drivers.

The BDE Configuration utility lists the actual files that contain the SQL Links drivers. For instance, the SQL Links driver for Oracle is called SQLORA32.dll. The driver for InterBase is called SQLINT32.dll, and so on, as shown in Table 8.1.

Table 8.1. DLLs associated with various SQL drivers.

The mere presence of the preceding DLLs is not enough, however, to connect you to a client/ server database. You will also need to be running a network protocol such as TCP/IP, and you will need local drivers and tools for the database supplied by the database vendor. The next section of this chapter discusses setting up TCP/IP on your computer.

Each vendor will have a different set of local drivers and tools for you to use. For instance, if you want to connect to Oracle, you need to install the Oracle SQL Net tools.

Your copy of BCB comes with a local version of InterBase. If you look at the right-hand portion of the taskbar at the bottom of your copy of Windows 95 or Windows NT, you should see the green and gray icon for the InterBase Server Properties applet. Other InterBase applets include the InterBase Server Manager (IBMGR32.exe) and InterBase Windows SQL (WISQL32.exe). (When reading these cryptic and inadvertently humorous 8/3 executable names, you should break the abbreviations up like this: IB-MGR-32.exe, not like this: IBM-GR-32.exe.)

If you are running BCB, your connection to InterBase will be set up automatically during program install. However, if you want to connect to Oracle, Sybase, or some other SQL server, you can be in for a rather complicated ordeal. The difficult part of these installs is almost always setting up the third-party tools. Borland's half of the equation is usually automatic, and occurs without effort on your part during BCB's install.

To get connected to Oracle or Sybase, the first thing to do is close BCB and all the Borland tools, and consult the manuals for your server. They will show you how to get the server set up, how to test the connection, and how to run some tools for managing your database. Once this part of the procedure is over, you can launch BCB, and you should be able to connect right away after establishing an alias. Aliases are described in the next section of this chapter, and in- depth in several of the upcoming chapters, including Chapter 15, "Working with the Local InterBase Server." They are also discussed in the readme file from the CD that accompanies this book. Of course, you have to have the client/server version of Delphi to connect to these databases.

There is a Sams Publishing book called the Database Developer's Guide with Delphi 2 (Ken Henderson, ISBN 0-672-30862-2), which goes into considerable depth on connecting to most of the major servers. The portion of the book you want to see is Chapter 24, "Delphi's Database Drivers Demystified." Almost anything this book says about Delphi databases will apply equally to BCB's databases. Delphi and BCB are sister and brother tools, and their approach to databases is almost identical.

I will, however, go to some lengths to ensure you are properly connected to InterBase, when I introduce that topic in Chapter 15. Until that time, there is no need for you to be connected to InterBase while reading this book. I should add, however, that connecting to InterBase is a simple task that should have been done for you automatically during the install of BCB. To check whether you are properly connected, try using the IBLOCAL alias set up by the install program for connecting to an InterBase table called Employee.gdb.

Aliases

You can create aliases inside any one of three tools:

• The SQL Explorer accessed through the Database | Explore menu option. From inside this tool, choose Object | New to create an alias.

  　

• The Database Desktop. This is a stand-alone program installed by default in the Program Files\Borland\Database Desktop directory. Choose Tools | Alias Manager from the DBD menu to create an alias.

  　

• The BDECFG32.exe program found in the directory where the BDE is installed. Turn to the Alias page in this program to create an alias.

Both Paradox and InterBase aliases are created automatically when you install BCB. You can study these aliases as guides when creating your own aliases. Also see the readme files on the CD that accompanies this book, and the section on creating ODBC aliases near the end of this chapter.

Various installation programs, such as Wise from Great Lakes Business Software (www.glbs.com, Tel (313) 981-4970, Fax

(313) 981-9746) and InstallShield, can create aliases for you automatically. If you need to add aliases to a client machine during installation, you should let one of these programs handle it for you. They will also automate the installation of the

BDE. InstallShield Express ships in the ISX directory found on some versions of the BCB CD.

Some Notes on Installing TCP/IP

In this section I briefly discuss the process of setting up TCP/IP on a Windows 95 machine. The process should be nearly identical on a Windows NT 4.0 machine, though the dialogs might have a slightly different name or appearance.

TCP/IP is the protocol of choice when connecting to client/server databases. It ships automatically with the 32-bit Windows products. To see if it is installed on your system, open the Control Panel and launch the Network applet. If you have TCP/IP installed, it will show up on the Configuration page of this applet, as shown in Figure 8.12.

FIGURE 8.12. The TCP/IP information from the Control Panel.

If TCP is not installed, you should push the Add button on the Configuration page and bring up the Select Network Component Type dialog. Select Protocol from the list of drivers, and again choose the Add button. In the Select Network Protocol dialog, choose Microsoft in the left-hand list box, and TCP/IP in the right-hand list box. Windows will then install the necessary software, which may require the use of your Windows Install CD-ROM.

You will probably also have to specify an IP address, subnet mask, gateway, and DNS server. This information can be garnered from your network administrator. If you are working on a small local network with Windows machines that you have set up in your office or home, you can ignore the DNS server, and can make up your own IP address, subnet mask, and gateway. For instance, the following numbers would do, as long as you are not connected to the real Internet, and are only talking to the machines in your home or office:

IP Address: 143.186.186.2

The other machines on your network should have the same subnet and gateway, but the IP address should be unique. For instance, the next machine should have an IP address of 143.186.186.3, and then 143.186.186.4, and so on. Remember, don't make up your own numbers if you are connected to the real Internet! If you have an Internet connection, contact your network administrator or Internet service provider (ISP).

　

---

NOTE: If you are appalled by my suggestion that people make up their own IP addresses, you should remember that many people connect their machines without being on the Internet. I do this all the time with two laptops when I am on the road showing BCB and Delphi. I also have a network at home with machines on it that are never connected directly to the Net.

I want to stress, however, that if you are connected to the Internet, it is very simple to ask your IS department for an IP address for your computer. There are plenty of IP addresses in this world, and everyone can afford to have several for their own use.

---

　

To check whether you are connected properly, open up a DOS window and try to ping one of the machines in your network. Ping is a built-in application that ships with Windows 95 and Windows NT. If you installed TCP/IP as explained previously, ping will be set up on your machine.

To get started, you can try to ping yourself:

Ping 143.186.186.2

Here is a built-in address for referencing your own machine:

Ping 127.0.0.1

Or you can try to ping one of the other machines in your network:

Ping 143.186.186.3

Here is the result of successful session:

c:\4dos>ping 143.186.186.2

Here is the result of a failed session:

c:\4dos>ping 143.186.186.3

Failed sessions usually occur because your machine is not configured properly or else the wires connecting you to the network are not set up correctly. (For instance, you might have forgotten to plug into the network!)

If you are attached to the Internet and have a DNS server, you can try to ping one of the big servers on the Net:

Ping compuserve.com

Here is successful session:

c:\>ping compuserve.com

Pinging compuserve.com is the same thing as pinging 149.174.207.12. In fact, it's the job of the DNS server (the Domain Name Server) to resolve a human-readable name such as compuserve.com into an IP address.

If you want to create a human-readable IP address on a local office or home network, you can edit the HOSTS files that ship with Windows 95 or Windows NT. Under Windows 95, you will find a sample HOSTS file called Hosts.sam in your Windows directory. Here is what this file looks like:

# Copyright (c) 1994 Microsoft Corp.

You can rename this file to HOSTS. with no extension, and then add your own list of IP address to it:

143.186.186.3 MarysPC

After doing this, you can ping the other machines with a human-readable name:

ping maryspc

Connecting to ODBC

ODBC is a popular means of connecting to databases. For many developers, ODBC plays the same role in their development that the BDE plays in the life of Borland developers. ODBC is so popular that Borland has added a high-performance ODBC socket to the BDE that enables you to access data through ODBC.

　

---

NOTE: It's important to understand that ODBC is not a database, but only a means of accessing a database. ODBC is a standard for creating drivers; it is a not a type of data. For instance, Borland developers commonly use SQL Links to connect to Oracle or Sybase. If you wanted, you could also use ODBC drivers in lieu of SQL Links, though this is usually not a wise thing to do because ODBC is often slow, while SQL Links are usually fast.

---

　

The main appeal of ODBC is its popularity. There are ODBC drivers for connecting to nearly every database imaginable. If Borland does not ship with drivers for the data you want to access, the logical thing to do would be to search for ODBC drivers and then use them from BCB through the ODBC socket layer currently under discussion in this section of the chapter.

Some copies of BCB ship with an ODBC driver for InterBase. Because this driver is readily available, I will use it as the model for this discussion.

To get started using ODBC, you should close down your Borland tools, open up the Windows Control Panel, and start one of its applets called, quite poetically, "32 Bit ODBC." This applet can be used to manage the ODBC connections on your machine.

As shown in Figure 8.13, on the bottom-right corner of the applet is a button with the word Driver on it, and another one right above it with the word Add on it. If you click either button you can see a list of the drivers available on your system.

FIGURE 8.13. The 32-Bit ODBC application.

On my system one of the available drivers is called InterBase 4.X driver by Visigenic (*.gdb). If I selected this button in the Add dialog, the dialog shown in Figure 8.14 would appear.

FIGURE 8.14. The dialog used for configuring an ODBC connection.

To set up a connection to the Employee.gdb table through the local InterBase server, I fill out the fields of the dialog, as shown in Figure 8.14. The database field of the dialog might have a path in it that looks like this:

c:\program files\borland\intrbase\examples\employee.gdb

The rest of the fields should look like this:

Data Source Name: InterBase Test

You should enter SYSDBA as the user name, and enter masterkey as the password. After entering all this information, you should be able to connect to the table by pressing the Test Connect button. However, you may not be able to run this test until you first press OK in the dialog, and then bring the dialog back up by pressing the Settings button from the main screen of the 32-Bit ODBC applet.

If all is working correctly, you can now bring up the BDE Configuration utility that ships with Borland C++Builder. On the drivers page pick New ODBC Connection to bring up the dialog for creating a new BDE connection, as shown in Figure 8.15. Fill in the fields as follows:

SQL_Link_Driver: ODBC_Test2

After creating the driver for the ODBC test, switch to the Alias page of the BDE Configuration Utility. Select New Alias and type in ODBCTest1. Set the Alias type to ODBC_Test2. Click OK, save your work from the File menu, and exit BDECFG.exe.

If BCB is already running, close it down. Now start up BCB and drop a TTable object on the main form. Select ODBCTest1 from the list of available aliases in the DatabaseName property. Now proceed as you normally would, selecting a TableName and attaching a TDataSource and TDBGrid object to the table. When prompted for a password, enter SYSDBA as the Username and masterkey as the password. If you want, you can relaunch the BDE configuration program and set the user name for this alias permanently to SYSDBA.

In the summary presented here, I have hardcoded in the names of the various drivers and aliases you create. You can, of course, name the alias anything you want, just as you can enter whatever names you want in the Data Source Name and Description fields of the ODBC Configuration dialog in the 32-Bit ODBC applet from the Control Panel.

FIGURE 8.15. The dialog for creating a new ODBC. connection.

Summary

In this chapter you have learned some of the fundamental facts you need to know to start accessing databases from BCB. In particular, you have learned about the following:

• The basics of using TTable and TQuery

  　

• The TDataModule object

  　

• The SQL Monitor and Database Explorer

  　

• TCP/IP and ODBC connectivity

Now that the groundwork has been laid, the next few chapters start digging into the objects that BCB uses to access databases. As a rule, this is not a particularly difficult subject, but there is a good deal of information that needs to be covered.

Once you have the facts that you need at your fingertips, you can start building real databases with BCB. C++Builder is one of the premier tools in the industry for accessing data, so you should be prepared to find yourself quickly writing powerful database applications that can be used by hundreds of people at one time.