Additional Migration Hints (FireDAC)

Go Up to Migrating BDE Applications to FireDAC

Hint 1

Some properties should be removed completely, because FireDAC does not have analogues:

• SessionName should be removed completely. But be careful, your application may be using multiple, same-named connections in different sessions.
• PrivateDir should be removed completely.

Note: That is done by FireDAC_Migrate_BDE.txt migration script.

Hint 2

Although FireDAC has an analogue to the BDE's TTable, named TFDTable, we recommend that you replace all TTables with TFDQuerys right at the migration.

Hint 3

The BDE application with persistent fields must be adjusted additionally. BDE does not provide or use persistent fields Origin and ProviderFlags properties, nor the queries DB dictionary to get the unique identifying fields. FireDAC provides and uses persistent fields Origin and ProviderFlags properties. The FireDAC_Migrate_BDE.txt migration script strips all TField.Origin values from DFM files. When Origin is empty (as it is in the BDE application), FireDAC uses the field name. But the default value of ProviderFlags does not include pfInKey, and FireDAC will not query the DB for PK fields. So, it will fail to get unique identifying fields and you must take one of the additional actions:

• Recreate persistent fields.
• Manually adjust ProviderFlags.
• Manually specify UpdateOptions.KeyFields.

Hint 4

Code snippets, such as:

Screen.Cursor := crSQLWait;
try
  ......
finally
  Screen.Cursor := crDefault;
end;

Should be replaced with:

uses
  FireDAC.Stan.Factory, FireDAC.UI.Intf;
  ......
var
  oWait: IFDGUIxWaitCursor;
  ......
  FDCreateInterface(IFDGUIxWaitCursor, oWait);
  oWait.StartWait;
  try
    ......
  finally
    oWait.StopWait;
  end;

Hint 5

FireDAC does not have a BDE API analogue. So, every code directly using the BDE API should be recoded using only the FireDAC API. There is no direct solution.

Hint 6

Many third-party products, such as reporting or m-tier libraries, require a DAC adapter unit. Please, contact a third-party product vendor for information about how to get an adapter.

Hint 7

EDBEngineError is the BDE-specific exception class. FireDAC has an analogue - the EFDDBEngineException class. When handling the BDE exceptions, the programmer uses the ErrorCode property to get an error type. FireDAC has the property type, which returns an enumerated value.

For example, change the following code:

if E is EDBEngineError then
begin
  case EDBEngineError(E).Errors[0].ErrorCode of
    DBIERR_KEYVIOL: MetaBaseDBError(SMb_DataSetInvalidPKeyValue, E);
end;

into:

if E is EFDDBEngineException then
begin
  case EFDDBEngineException(E).Kind of
    ekUKViolated: MetaBaseDBError(SMb_DataSetInvalidPKeyValue, E);
end;

Hint 8

The TBatchMove and TFDBatchMove components are very different in many ways. You will need to rework any code that uses the TBatchMove component.

Hint 9

The TFDConnection.OnLogin event is incompatible with the TDatabase.OnLogin event parameters list. So, for example, you will need to replace the following handler:

procedure TMyDataModule.dbLogin(Connection: TFDConnection; LoginParams: TStrings);
begin
  LoginParams.Values['USER NAME'] := 'me';
  LoginParams.Values['PASSWORD'] := 'pwd';
end;

with this one:

procedure TMyDataModule.dbLogin (AConnection: TFDCustomConnection; const AConnectionDef: IFDStanConnectionDef);
begin
  AConnectionDef.UserName := 'me';
  AConnectionDef.Password := 'pwd';
end;

Hint 10

When the application uses BDE heterogeneous queries, with FireDAC it should use the Local SQL.

Hint 11

To enable multi-threading with BDE, the application may set TSession.AutoSessionName to True. FireDAC does not support the concept of the named sessions. Instead, you will need to switch your application from using TFDQuery.ConnectionName (binding by name) to TFDQuery.Connection (binding by reference). See more details regarding multi-threading application development with FireDAC.