Conseils supplémentaires sur la migration dbExpress (FireDAC)

De RAD Studio
Aller à : navigation, rechercher

Remonter à Migration des applications dbExpress vers FireDAC


Informations générales

Méthodes et propriétés incompatibles

Plusieurs propriétés sont retirées automatiquement par le script de migration FireDAC_Migrate_DBX.txt, car FireDAC n'a pas d'équivalents :

  • TSQLConnection :
    • AutoClone - FireDAC prend en charge plusieurs instructions actives par connexion pour toutes les bases de données ;
    • LocaleCode - n'est pas applicable ;
    • UniqueID - n'est pas applicable ;
    • GetDriverFunc - FireDAC utilise une architecture de pilotes différente ;
    • LibraryName - FireDAC utilise une architecture de pilotes différente ;
    • ValidatePeerCertificate - n'est pas prise en charge.
  • TCustomSQLDataSet :
    • MaxBlobSize - FireDAC récupère une valeur BLOB toujours en taille maximale.

Plusieurs propriétés et méthodes doivent être retirées ou remplacées manuellement, car FireDAC n'a pas d'équivalents directs et l'application peut s'interrompre :

  • IConnectionAdmin :
    • GetDelegateDriverNames - FireDAC ne prend pas en charge le concept de pilote "délégué" ;
    • RegisterDriver / UnregisterDriver - un pilote FireDAC est recensé automatiquement lors de sa liaison à une application.
  • TSQLConnection :
    • GetCommandTypes - les types de commandes FireDAC sont énumérés par TFDPhysCommandKind ;
    • GetServerMethodNames - lorsque la connexion FireDAC DataSnap est employée, utilisez alors la requête d'informations méta mkProcs pour obtenir la liste des méthodes du serveur ;
    • SetTraceEvent / TraceCallbackEvent - FireDAC a une API de suivi / surveillance différente ;
    • MaxStmtsPerConn - FireDAC autorise un nombre illimité d'instructions par connexion ;
    • VendorLib - utilisez la propriété TFDPhysXxxDriverLink.VendorLib ou FDDrivers.ini ;
    • LoadParamsOnConnect / ParamsLoaded / LoadParamsFromIniFile - FireDAC a une API de définition de connexion différente ;
  • TCustomSQLDataSet :
    • GetCommandNames - les noms de commandes FireDAC sont énumérés par TFDPhysCommandKind et TFDPhysMetaInfoKind ;
    • SetSchemaInfo, SchemaName, GetMetadata - utilisez TFDMetaInfoQuery à la place ;
    • ParseSelectSql, ParseDeleteSql, ParseUpdateSql, ParseInsertSql - FireDAC ne prend pas en charge cette API. Vous pouvez utiliser à la place UpdateOptions.UpdateTableName, TField.ProviderFlags, etc.
  • TSQLMonitor - FireDAC a une API de suivi / surveillance différente.

FireDAC émule de nombreuses propriétés et méthodes dbExpress incompatibles. Pour activer l'émulation, le script de migration FireDAC_Migrate_DBX.txt inclut l'unité FireDAC.DBX.Migrate dans la clause uses de votre application FireDAC.

Remarque : Pour obtenir le contrôle complet, remplacez les méthodes émulées par les méthodes FireDAC natives.

Gestion des exceptions

TDBXError est la classe d'exception spécifique à dbExpress. FireDAC a une classe équivalente, la classe EFDDBEngineException.

Lors de la gestion des exceptions de dbExpress, le programmeur utilise la propriété Message ou ErrorCode pour obtenir le type d'erreur. FireDAC a la propriété Kind, qui renvoie une valeur énumérée. Pour plus d'informations, voir la gestion des erreurs dans FireDAC.

Par exemple, remplacez le code dbExpress suivant par du code FireDAC :

  • Pour Delphi :
if (E is TDBXError) and (Pos('unique key violated', TDBXError(E).Message) > 0) then
  MetaBaseDBError(SMb_DataSetInvalidPKeyValue, E);
if (E is EFDDBEngineException) and (EFDDBEngineException(E).Kind = ekUKViolated) then
  MetaBaseDBError(SMb_DataSetInvalidPKeyValue, E);

Curseur d'attente

Par exemple, remplacez le code dbExpress suivant par du code FireDAC :

  • Pour Delphi :
Screen.Cursor := crSQLWait;
try
  ......
finally
  Screen.Cursor := crDefault;
end;
uses
  FireDAC.Stan.Factory, FireDAC.UI.Intf;
  ......
var
  oWait: IFDGUIxWaitCursor;
  ......
  FDCreateInterface(IFDGUIxWaitCursor, oWait);
  oWait.StartWait;
  try
    ......
  finally
    oWait.StopWait;
  end;

Intégration tierce

De nombreux produits tiers, comme les outils de rapports ou les bibliothèques multi-niveaux, requièrent une unité d'adaptateur DAC. Contactez le fournisseur du produit tiers pour savoir comment vous procurer un adaptateur pour FireDAC.

API de bas niveau

FireDAC n'a pas d'équivalent de l'API dbExpress / Data.DBXCommon. Le code qui utilise l'API dbExpress / Data.DBXCommon doit être à nouveau codé, en utilisant uniquement l'API FireDAC (API des couches DatS et Phys). Pour de plus amples informations, voir FireDAC (présentation générale). Il n'existe pas de solution directe.

Pilotes et connexions

Définition du pilote et de la bibliothèque client

dbExpress a de nombreux paramètres de liaison de pilote, tels que DriverUnit, DriverPackageLoader, DriverAssemblyLoader, MetaDataPackageLoader, MetaDataAssemblyLoader, GetDriverFunc, LibraryName, LibraryNameOsx. Aucun d'entre eux n'a d'équivalent dans FireDAC. A la place, un pilote FireDAC peut être lié soit statiquement, soit dynamiquement à l'aide des packages FireDAC préconstruits. Pour de plus amples informations, voir le déploiement d'une application avec FireDAC.

dbExpress vous permet de spécifier le paramètre VendorLib dans les paramètres de connexion. FireDAC n'effectue pas cette prise en charge. Pour configurer un pilote FireDAC, définissez la valeur de la propriété TFDPhysXxxDriverLink.VendorLib ou utilisez le fichier FDDrivers.ini. Pour de plus amples informations, voir la configuration des pilotes FireDAC.

Par exemple, remplacez le code dbExpress suivant par du code FireDAC :

  • Pour Delphi :
SQLConnection1.Params.Add('VendorLib=' + ExtractFilePath(Application.ExeName) + 'libmysql.dll');
FDPhysMySQLDriverLink1.VendorLib := ExtractFilePath(Application.ExeName) + 'libmysql.dll';

Définition d'une connexion

Dans dbExpress, un ensemble stocké de paramètres de connexion est appelé une connexion nommée et il est enregistré dans le fichier dbxConnections.ini. Pour gérer ces connexions nommées dans une application, vous pouvez utiliser la référence d'interface IConnectionAdmin renvoyée par GetConnectionAdmin. Dans FireDAC, l'ensemble stocké de paramètres de connexion est appelé la définition de la connexion et il est enregistré dans le fichier FDConnectionDefs.ini (voir la définition d'une connexion dans FireDAC). Utilisez le composant FDManager pour gérer les définitions de connexions.

Dans dbExpress, pour charger à l'exécution les paramètres de connexion à partir d'une connexion nommée (automatiquement), l'application utilise ConnectionName et LoadParamsOnConnect ou LoadParamsFromIniFile. Une application FireDAC définit uniquement ConnectionDefName.

Par exemple, remplacez le code dbExpress suivant par du code FireDAC :

  • Pour Delphi :
SQLConnection1.ConnectionName := 'IBConn';
// loads parameters of 'IBConn' named connection from dbxConnections.ini
SQLConnection1.LoadParamsFromIniFile;
SQLConnection1.Connected := True;
// will load parameters of 'IBConn' connection definition from FDConnectionDefs.ini
FDConnection1.ConnectionDefName := 'IBConn';
FDConnection1.Connected := True;

Connexion à une base de données

dbExpress utilise les dialogues de connexion VCL ou FireMonkey standard. FireDAC requiert l'utilisation du composant TFDGUIxLoginDialog et définit TFDConnection.LoginDialog sur ce composant (pour de plus amples informations, voir l'établissement d'une connexion dans FireDAC).

L'événement TFDConnection.OnLogin est incompatible avec la liste des paramètres de l'événement TSQLConnection.OnLogin.

Vous devez changer la déclaration de gestionnaire suivante (après l'application de FireDAC_Migrate_DBX.txt) en code FireDAC :

  • Pour Delphi :
procedure TMyDataModule.dbLogin(Database: TFDConnection; LoginParams: TStrings);
begin
  LoginParams.Values['User_Name'] := 'me';
  LoginParams.Values['Password'] := 'pwd';
end;
procedure TMyDataModule.dbLogin(Database: TFDCustomConnection; LoginParams: TFDConnectionDefParams);
begin
  LoginParams.Values['User_Name'] := 'me';
  LoginParams.Values['Password'] := 'pwd';
end;

Contrôle des transactions

L'API de contrôle des transactions de dbExpress prend en charge les transactions actives multiples mais non imbriquées. Pour les transactions multiples, elle utilise l'approche basée sur l'ID.

FireDAC prend en charge les transactions multiples actives et imbriquées (pour de plus amples informations, voir Gestion des transactions (FireDAC)). Pour les transactions multiples, une application peut utiliser plusieurs TFDTransaction connectés au même TFDConnection. Pour les transactions imbriquées, les appels de StartTransaction / Commit / Rollback peuvent être imbriqués.

L'unité FireDAC.DBX.Migrate émule l'API de contrôle des transactions dbExpress, mais ne prend pas en charge les transactions actives multiples. Pour prendre en charge des transactions actives multiples, le code doit être changé.

Par exemple, remplacez le code suivant par du code FireDAC :

  • Pour Delphi :
uses
  FireDAC.DBX.Migrate;
...
var
  oTx1: TFDDBXTransaction;
...
oTx1 := FDConnection1.BeginTransaction;
try
  ...
  FDConnection1.CommitFreeAndNil(oTx1);
except
  FDConnection1.RollbackFreeAndNil(oTx1);
  raise;
end;
FDTransaction1.StartTransaction;
try
  ...
  FDTransaction1.Commit;
except
  FDTransaction1.Rollback;
  raise;
end;

Suivi

Les capacités de suivi de dbExpress sont basées sur le composant TSQLMonitor et le gestionnaire d'événement TSQLConnection.TraceCallbackEvent. Les capacités de suivi de FireDAC sont basées sur l'ensemble de composants TFDMoniXxxClientLink et le paramètre de définition de connexion MonitorBy=Xxx (pour de plus amples informations, voir Suivi et surveillance (FireDAC).

Les deux bibliothèques ne sont pas compatibles dans cette zone, ainsi la configuration du suivi dbExpress doit être complètement remplacée par la configuration FireDAC. Par exemple, pour activer le suivi des sorties pour la connexion FireDAC, utilisez le code suivant :

  • Pour Delphi :
FDMoniRemoteClientLink1.Tracing := True;
FDConnection1.Params.Add('MonitorBy=Remote');
FDConnection1.Connected := True;

Informations Méta de connexion

dbExpress fournit des propriétés de métadonnées spécifiques à la connexion par le biais de la propriété TSQLConnection.MetaData. Cette propriété renvoie une référence à l'objet TDBXDatabaseMetaData. FireDAC fournit des propriétés de métadonnées similaires par le biais de la propriété TFDConnection.ConnectionMetaDataIntf. Cette propriété renvoie une référence à l'interface IFDPhysConnectionMetadata.

Les API TDBXDatabaseMetaData et IFDPhysConnectionMetadata ne sont pas compatibles.

Ensembles de données et commandes

Informations générales

Voici les différences majeures entre les ensembles de données dbExpress et FireDAC :

  • Les ensembles de données dbExpress sont unidirectionnels. Un ensemble de données dbExpress ne met pas en cache les enregistrements extraits. Une application ne peut pas définir une position aléatoire dans un ensemble de résultats.
  • Les ensembles de données dbExpress ont des fonctionnalités côté client très limitées. Ils ne prennent pas en charge le tri, le filtrage, les étendues, les agrégats, etc.
    • Les ensembles de données FireDAC ont des fonctionnalités côté client avancées.
  • Les ensembles de données dbExpress sont accessibles en lecture seule. Ils ne prennent pas en charge l'édition des enregistrements, la validation automatique des mises à jour, les mises à jour en cache, etc.
    • Les ensembles de données FireDAC ont des fonctionnalités de mise à jour avancées.

Pour éviter les limitations dbExpress citées ci-dessus, de nombreuses applications dbExpress utilisent le composant TDataSetProvider et un composant TClientDataSet. Après la migration d'une application dbExpress vers FireDAC, vous devez supprimer les composants TDataSetProvider et TClientDataSet, et utiliser uniquement les ensembles de données FireDAC.

Compatibilité

Les ensembles de données dbExpress (l'utilisation des ensembles de données dbExpress, de TDataSetProvider et de TClientDataSet) et les ensembles de données FireDAC ont un traitement des données légèrement différent. Pour forcer la compatibilité des ensembles de données FireDAC, définissez FormatOptions.DataSnapCompatibility sur True.

Les ensembles de données dbExpress utilisent la liaison de paramètres positionnelle. Cela signifie que chaque paramètre de la collection Params est mis en correspondance avec les marqueurs de paramètres dans le texte de la commande SQL par position, et non par nom. FireDAC utilise la liaison de paramètres nommés par défaut.

Des problèmes peuvent survenir dans les cas suivants :

  • le même marqueur de paramètre nommé se produit au moins 2 fois dans le texte de la commande SQL.
  • l'ordre des paramètres dans la collection Params est différent de l'ordre des marqueurs de paramètres dans le texte de la commande SQL.

Pour résoudre ces problèmes, envisagez de :

  • changer le texte de la commande SQL et de rendre unique tous les noms de marqueurs de paramètres.
  • définir l'ensemble de données FireDAC Params.BindMode sur pbByNumber.

Champs persistants

L'application dbExpress avec champs persistants doit être également ajustée.

dbExpress ne fournit pas ou n'utilise pas les propriétés Origin et ProviderFlags des champs persistants, ni le dictionnaire de requêtes de base de données pour obtenir les champs d'identification unique. FireDAC fournit et utilise les propriétés Origin et ProviderFlags des champs persistants. Le script de migration FireDAC_Migrate_DBX.txt supprime toutes les valeurs TField.Origin des fichiers DFM. Lorsque Origin est vide (comme c'est le cas dans l'application dbExpress), FireDAC utilise le nom du champ. Mais la valeur par défaut de ProviderFlags n'inclut pas pfInKey, et FireDAC n'interroge pas la base de données pour obtenir les champs de clé primaire. Il ne peut donc pas obtenir les champs d'identification unique et vous devez effectuer l'une des actions supplémentaires suivantes :

  • Recréer des champs persistants.
  • Ajuster manuellement ProviderFlags.
  • Spécifier manuellement UpdateOptions.KeyFields.

TSQLTable

Le TFDTable de FireDAC est analogue au TTable du BDE et au TSQLTable de dbExpress. Nous vous recommandons de remplacer tous les TSQLTable par TFDQuery lors de la migration vers FireDAC.

TSQLDataSet

FireDAC n'a pas de classe analogue TSQLDataSet directe.

Il existe plusieurs options de remplacement :

Par exemple, remplacez le code dbExpress suivant par du code FireDAC :

  • Pour Delphi :
SQLDataSet1.CommandType := ctQuery;
SQLDataSet1.CommandText := 'select * from tab';
SQLDataSet1.Open;
SQLDataSet2.CommandType := ctTable;
SQLDataSet2.CommandText := 'tab';
SQLDataSet2.Open;
FDQuery1.SQL.Text := 'select * from tab';
FDQuery1.Open;
FDTable1.TableName := 'tab';
FDTable1.Open;

Par exemple, remplacez le code dbExpress suivant par du code FireDAC :

  • Pour Delphi :
SQLDataSet1.SetSchemaInfo(stTables, '', '', '');
SQLDataSet1.Open;
SQLDataSet2.SetSchemaInfo(stColumns, 'TAB', '', '');
SQLDataSet2.Open;
FDMetaInfoQuery1.MetaInfoKind := mkTables;
FDMetaInfoQuery1.Open;
FDMetaInfoQuery2.ObjectName := 'TAB';
FDMetaInfoQuery2.Open;

Voir aussi