Questions relatives à TFDManager et TFDConnection

Remonter à FAQ (FireDAC)

Cette rubrique liste des questions et réponses relatives à TFDManager et TFDConnection.

Q1 : J'ai une classe de module de données de base comportant TFDManager. Lorsque je crée une classe descendante, j'obtiens l'erreur 'L'application doit comporter un seul FDManager'. Quel est le problème ?

R : Il ne peut y avoir qu'un seul FDManager par application. Au lieu de créer cela explicitement dans vos classes, faites référence à un objet singleton via la fonction FDManager.

Q2 : Dans mon groupe de projets, j'ai plusieurs projets Delphi différents (applications), chacun comportant son propre DataModule et son propre FDManager. Si j'ouvre simultanément plus d'un module de données (pour copier ou comparer des éléments), j'obtiens une erreur indiquant qu'il ne peut y avoir qu'un seul FDManager par application, et l'un d'entre eux est immédiatement supprimé de l'un des modules de données.

R : Avez-vous vraiment besoin de TFDManager ? Il n'est pas nécessaire que l'application crée explicitement le TFDManager. Il est nécessaire de définir les options et les fichiers de configuration à la conception.

Q3 : Je perds tout le temps mes FDManager et je dois sans arrêt les recréer. Cela peut-il être résolu ?

R : Non, cela ne peut pas être résolu car il n'est possible de créer qu'un seul TFDManager à la conception ou à l'exécution. Lorsqu'il existe plusieurs TFDManager, FireDAC ne sait pas lequel utiliser. Voir aussi la Q1.

Q4 : FireDAC supporte-t-il le pooling de connexion ?

R : Oui, il le supporte. En général, le pooling de connexion conserve un pool de connexions "physiques" ouvertes, et lorsque TFDConnection.Connected est défini sur True, FireDAC récupère une connexion "physique" dans le pool et l'utilise. Lorsque TFDConnection.Connected est défini sur False, la connexion "physique" n'est pas fermée, mais replacée dans le pool.

Pour utiliser le pooling de connexion dans FireDAC, ajoutez simplement Pooled=True à votre définition de connexion. Aucune autre action spéciale n'est requise. Pour plus de détails, lire Multi-threading.

Q5 : L'éditeur de connexion semble ignorer FDPhysFBDriverLink1.VendorLib et utilise un pilote codé en dur.

R : Vous devez définir VendorLib avant la première connexion en utilisant ce pilote. Une fois la connexion établie, le client du SGBD est chargé.

A la conception, pour être certain que vos propriétés TFDPhysXXXDriverLink sont utilisées, vérifiez que TFDPhysXXXDriverLink apparaît en premier dans le module de données ou dans l'ordre de création de la fiche. Puis, redémarrez l'EDI si vous le souhaitez.

A l'exécution, utilisez la méthode Release de liaison du pilote :

 FDConnection1.Close;
 ...
 FDConnectionN.Close;
 
 FDPhysFBDriverLink.VendorLib := 'c:\fbclient.dll';
 FDPhysFBDriverLink.Release;
 
 FDConnection1.Open;
 ...
 FDConnectionN.Open;

Une autre option consiste à définir un pilote virtuel. Pour plus de détails, voir Configuration des pilotes. Par exemple :

 [FB_Embedded]
 BaseDriverID=FB
 VendorLib = C:\fb\fbembed.dll

Utilisez le pilote FB_Embedded comme DriverID à la conception. A l'exécution, vous pouvez utiliser FDDrivers.ini ou simplement configurer TFDPhysXXXDriverLink.