The dbExpress VCL component's implementation has changed with minimal change to the API. Most applications are not affected by changes to the dbExpress VCL. However, there are some new methods, properties, events, constants, and enums.

In the DbxCommon unit, there are several new classes that extend existing classes and have a suffix of "Ex". These are temporary classes introduced to avoid breaking the interface compatibility with the versions shipped earlier in 2007. In the next release, these additional fields and methods will be moved to the non-Ex version of the classes.

The dbExpress 3 metadata was not rich enough for database tooling and did not support all of the metadata types expected from an ADO.NET 2.0 driver. New metadata providers support provides much greater capability. 

New metadata providers for 9 different database backends are written completely in Delphi. Full source code to all metadata providers is included in the product.

Each provider is composed of a metadata reader and metadata writer implementation. The metadata readers are in the new DbxReadOnlyMetaData package and the metadata writers are in the DbxMetaData package. The dbExpress drivers and the new ADO.NET AdoDbx Client driver only need the metadata reader capabilities. Many database applications only need to read metadata, not write to it. By separating read and write capabilities, application deployments sizes can be reduced.

The metadata providers are detached from the driver, so that one metadata provider can be used for multiple driver implementations as long as the database backend is the same. Data Explorer also takes advantage of metadata providers to provide metadata support for other database ADO.NET drivers. 

The provider is not bound to a driver, but to a database back end. There is a new property called TDBXPropertyNames.MetaDataPackageLoader in the dbxdrivers.ini files that can be set to a TDBXCommandFactory object. This command factory implementation creates a TDBXCommand that can execute metadata commands. This approach allows multiple driver implementations for a specific database backend to use the same metadata provider. Data Explorer also takes advantage of this architecture to provide dbExpress 4 structured metadata for ADO.NET drivers from other vendors. The decoupling of driver and metadata provider also benefits "thin" driver implementations. If metadata commands can be serviced on a server, there is no need to have the metadata provider logic on the client.

There are several directories for the metadata provider source code. Units of interest to applications have been placed in the "provider" directory. Applications should avoid creating dependencies on units outside of this directory. However, implementors of dbExpress metadata must extend from abstract reader and writer base classes that are outside of the provider directory.

A new unit DBXMetaDataNames has been provided to read metadata. The existing dbExpress class TDBXMetaDataCommands and its extension, TDBXMetaDataCommandsEx, provide a set of constants to read various types of metadata. Set the TDBXCommand.CommandType property to TDBXCommandTypes.DBXMetadata and set TDBXCommand.Text to one of the constants in TDBXMetaDataCommands or TDBXMetaDataCommandsEx to acquire the designated metadata. TDBXCommand.ExecuteQuery returns a TDBXReader to access the metadata. The new classes in DBXMetaDataNames describe and provide access to this metadata's columns.

Support for creating SQL dialect sensitive CREATE, ALTER, and DROP statements is provided in Data Explorer. dbExpress also exposes a DbxMetaDataProvider class that surfaces this capability for applications. This slightly increases the size of application, since the metadata writers must be included. The ability to generically create tables is useful for many applications. The interface allows you to describe what a table and its columns look like and pass this description to the TdbxMetaDataProvider.CreateTable method. Here is a simple example that shows how to create a table with an int32 column named "C1", a decimal with a precision of 10 and scale of 2 named "C2", and a character based column with a precision of 32 named "C3".

var
 MetaDataTable: TDBXMetaDataTable;
 DataGenerator: TDbxDataGenerator;
 Command: TDBXCommand;
 Row: Integer;
begin
 MetaDataTable := TDBXMetaDataTable.Create;
 MetaDataTable.TableName := 'QCXXX_TABLE';
 MetaDataTable.AddColumn(TDBXInt32Column.Create('C1'));
 MetaDataTable.AddColumn(TDBXDecimalColumn.Create('C2', 10, 2));
 MetaDataTable.AddColumn(TDBXUnicodeCharColumn.Create('C3', 32));
 MetaDataProvider.CreateTable(MetaDataTable);
end

For package based deployment, the following packages must be included:

• Borland.Data.DBXClient.dll
• Borland.Data.DBXReadOnlyMetaData.dll
• Borland.Data.DBXCommonDriver.dll
• Borland.Data.DBXMetaData.dll

The bulk of the work in creating new metadata providers is extending the TDBXMetaDataReader and TDBXMetaDataWriter abstract base classes.

The VCL components in the SqlExpr unit still work with drivers that provide the more limited dbExpress 3 metadata. However, Data Explorer only works with dbExpress 4 metadata. 

Note that Delphi includes metadata for 9 different database backends. Thus any dbExpress driver implementation for the 9 backends supported can reuse the metadata provider with their driver implementation.

DBXClient is a thin dbExpress 4 driver that remotes the dbExpress 4 framework interface over a pluggable network based transport. In this release, a TCP/IP transport is supported. The driver uses a JSON/RPC (Java Script Object Notation) based streaming protocol. 

The DBXClient is implemented in 100% Object Pascal. Its source code is included in the product.

In this release, DBXClient can only connect to Blackfish SQL. Blackfish SQL is a Delphi for .NET version of JBuilder's JDataStore. 

To use the DBXClient driver with Blackfish SQL, add the DBXClient unit to the uses clause.

DBXClient needs no database client library installed when you deploy your application. DBXClient is 100% Delphi and can be directly linked into your application as a single .exe file. 

If you prefer to use package based deployment, you need to include the following packages:

• DBXClient100.bpl
• DBXReadOnlyMetaData100.bpl
• DBXCommonDriver100.bpl

The DBXDynalink driver unit has been moved from the DBXCommonDriver package into the DBXDynalinkDriver package. With the introduction of the DBXClient driver, CodeGear now provides non-Dynalink based drivers.

New units have been added in the DbxDynalinkDriver package for all 8 of Dynalink drivers:

• DBXDb2
• DBXInformix
• DBXInterbase
• DBXMsSql
• DBXMySql
• DBXOracle
• DBXSybaseASA
• DBXSybaseASE

The Dynalink drivers can be linked into a single executable, but you still need to deploy the Dynalink libraries themselves and the database vendor client libraries. 

For package based deployment, the following packages must be included:

• DBXCommonDriver100.bpl
• DBXReadOnlyMetaData100.bpl
• DBXDynalinkDriver100.bpl

For package based deployment on the .NET platform, the following assemblies must be included:

• Borland.Data.DBXCommonDriver.dll
• Borland.Data.DBXReadOnlyMetaData.dll
• Borland.Data.DBXDynalinkDriver.dll

This is a collection of classes that extend the capabilities of Dunit to facilitate database testing. The qcreport and cts sample Dunit tests provide good examples of how to make use of DBTest. TestCaseExtension contains non-database related extensions to Dunit and the DBXTest unit contains database related extensions.

New units have been added to the DbxDynalinkDriver package for all 8 of Dynalink drivers:

-s:<TestName> command line can be used to execute just a single method in a Dunit test case. This is useful for debugging a single bug. See the TestCaseExtension unit.

There are several methods for creating default connection and metadata provider. See the DBXTest unit.

There is a simple, extensible data generator. See the DBXDataGenerator unit.

dbExpress Framework 

TDBXMetaDataCommands 

TDBXMetaDataCommandsEx