Name 

Description 

Associating a Dataset with Database and Session Connections 

In order for a BDE-enabled dataset to fetch data from a database server it needs to use both a database and a session.
Databases represent connections to specific database servers. The database identifies a BDE driver, a particular database server that uses that driver, and a set of connection parameters for connecting to that database server. Each database is represented by a TDatabase component. You can either associate your datasets with a TDatabase component you add to a form or data module, or you can simply identify the database server by name and let Delphi generate an implicit database component... more 

Binding Parameters 

When you prepare and execute a stored procedure, its input parameters are automatically bound to parameters on the server.
TStoredProc lets you use the ParamBindMode property to specify how parameters should be bound to the parameters on the server. By default ParamBindMode is set to pbByName, meaning that parameters from the stored procedure component are matched to those on the server by name. This is the easiest method of binding parameters.
Some servers also support binding parameters by ordinal value, the order in which the parameters appear in the stored procedure. In this case the order in which you... more 

Caching BLOBs 

BDE-enabled datasets all have a CacheBlobs property that controls whether BLOB fields are cached locally by the BDE when an application reads BLOB records. By default, CacheBlobs is True, meaning that the BDE caches a local copy of BLOB fields. Caching BLOBs improves application performance by enabling the BDE to store local copies of BLOBs instead of fetching them repeatedly from the database server as a user scrolls through records.
In applications and environments where BLOBs are frequently updated or replaced, and a fresh view of BLOB data is more important than application performance, you can set CacheBlobs to... more 

Controlling Read/Write Access to Local Tables 

Like any table type dataset, TTable lets you control read and write access by your application using the ReadOnly property.
In addition, for Paradox, dBASE, and FoxPro tables, TTable can let you control read and write access to tables by other applications. The Exclusive property controls whether your application gains sole read/write access to a Paradox, dBASE, or FoxPro table. To gain sole read/write access for these table types, set the table component's Exclusive property to True before opening the table. If you succeed in opening a table for exclusive access, other applications cannot read data from or write data... more 

Importing Data from Another Table 

You can use a table component's BatchMovemethod to import data from another table. BatchMove can

• Copy records from another table into this table.
• Update records in this table that occur in another table.
• Append records from another table to the end of this table.
• Delete records in this table that occur in another table.

BatchMove takes two parameters: the name of the table from which to import data, and a mode specification that determines which import operation to perform. The following table describes the possible settings for the mode specification:
BatchMove import modes  

Working with BDE Handle Properties 

You can use BDE-enabled datasets without ever needing to make direct API calls to the Borland Database Engine. The BDE-enabled datasets, in combination with database and session components, encapsulate much of the BDE functionality. However, if you need to make direct API calls to the BDE, you may need BDE handles for resources managed by the BDE. Many BDE APIs require these handles as parameters.
All BDE-enabled datasets include three read-only properties for accessing BDE handles at runtime:

• Handle is a handle to the BDE cursor that accesses the records in the dataset.
• DBHandle is a handle to the... more 

Renaming a Table 

To rename a Paradox or dBASE table at runtime, call the table's RenameTable method. For example, the following statement renames the Customer table to CustInfo:  

Specifying a dBASE Index File 

For most servers, you use the methods common to all table type datasets to specify an index. These methods are described in Sorting records with indexes.
For dBASE tables that use non-production index files or dBASE III PLUS-style indexes (*.NDX), however, you must use the IndexFiles and IndexNameproperties instead. Set the IndexFiles property to the name of the non-production index file or list the .NDX files. Then, specify one index in the IndexName property to have it actively sorting the dataset.
At design time, click the ellipsis button in the IndexFiles property value in the Object Inspector to... more 

Specifying the Table Type for Local Tables 

If an application accesses Paradox, dBASE, FoxPro, or comma-delimited ASCII text tables, then the BDE uses the TableType property to determine the table's type (its expected structure). TableType is not used when TTable represents an SQL-based table on a database server.
By default TableType is set to ttDefault. When TableType is ttDefault, the BDE determines a table's type from its filename extension. The following table summarizes the file extensions recognized by the BDE and the assumptions it makes about a table's type:
Table types recognized by the BDE based on file extension  

Using TQuery 

TQuery represents a single Data Definition Language (DDL) or Data Manipulation Language (DML) statement (For example, a SELECT, INSERT, DELETE, UPDATE, CREATE INDEX, or ALTER TABLE command). The language used in commands is server-specific, but usually compliant with the SQL-92 standard for the SQL language. TQuery implements all of the basic functionality introduced by TDataSet, as well as all of the special features typical of query-type datasets.
Because TQuery is a BDE-enabled dataset, it must usually be associated with a database and a session. (The one exception is when you use the TQuery for a heterogeneous query.)... more 

Using TStoredProc 

TStoredProc represents a stored procedure. It implements all of the basic functionality introduced by TDataSet, as well as most of the special features typical of stored procedure-type datasets.
Because TStoredProc is a BDE-enabled dataset, it must be associated with a database and a session. Once the dataset is associated with a database and session, you can bind it to a particular stored procedure by setting the StoredProcName property.
TStoredProc differs from other stored procedure-type datasets in the following ways:

• It gives you greater control over how to bind parameters.
• It provides support for Oracle overloaded stored... more 

Using TTable 

TTable encapsulates the full structure of and data in an underlying database table. It implements all of the basic functionality introduced by TDataSet, as well as all of the special features typical of table type datasets.
Because TTable is a BDE-enabled dataset, it must be associated with a database and a session. Once the dataset is associated with a database and session, you can bind it to a particular database table by setting the TableName property and, if you are using a Paradox, dBASE, FoxPro, or comma-delimited ASCII text table, the TableType property.

Using BDE-enabled Datasets 

BDE-enabled datasets use the Borland Database Engine (BDE) to access data. They inherit the common dataset capabilities described in Understanding datasets, using the BDE to provide the implementation. In addition, all BDE datasets add properties, events, and methods for

• Associating a dataset with database and session connections.
• Caching BLOBs.
• Obtaining a BDE handle.

There are three BDE-enabled datasets:

• TTable, a table type dataset that represents all of the rows and columns of a single database table. See Using TTable for a description of features unique to TTable.
• TQuery, a query-type dataset that... more 

Creating Heterogenous Queries 

TQuery supports heterogeneous queries against more than one server or table type (for example, data from an Oracle table and a Paradox table. When you execute a heterogeneous query, the BDE parses and processes the query using Local SQL. Because BDE uses Local SQL, extended, server-specific SQL syntax is not supported. 

Obtaining an Editable Result Set 

To request a result set that users can edit in data-aware controls, set a query component's RequestLive property to True. Setting RequestLive to True does not guarantee a live result set, but the BDE attempts to honor the request whenever possible. There are some restrictions on live result set requests, depending on whether the query uses the local SQL parser or a server's SQL parser.

• Queries where table names are preceded by a BDE database alias (as in heterogeneous queries) and queries executed against Paradox or dBASE are parsed by the BDE using Local SQL. When queries use the local... more 

Updating a Read-only Result Set 

Applications can update data returned in a read-only result set if they are using cached updates.
If you are using a client dataset to cache updates, the client dataset or its associated provider can automatically generate the SQL for applying updates unless the query represents multiple tables. If the query represents multiple tables, you must indicate how to apply the updates:
If all updates are applied to a single database table, you can indicate the underlying table to update in an OnGetTableName event handler.
If you need more control over applying updates, you can associate the query with an... more 

Working with Oracle Overloaded Stored Procedures 

Oracle servers allow overloading of stored procedures; overloaded procedures are different procedures with the same name. The stored procedure component's Overload property enables an application to specify the procedure to execute.
If Overload is zero (the default), there is assumed to be no overloading. If Overload is one (1), then the stored procedure component executes the first stored procedure it finds on the Oracle server that has the overloaded name; if it is two (2), it executes the second, and so on.