Je pense que cela peut être un bug FireDAC (ou IDE) qui a été introduit entre Delphi Seattle et Tokyo (10.2). J'ai trouvé que je pouvais le reproduire comme suit:
Créer un nouveau projet multi-dispositif (FMX) à Seattle . Ajoutez un module de données au projet et ajoutez-lui une connexion FDC.
Ajoutez un module de données au projet. J'ai configuré FDConnection pour utiliser le pilote MSSQL, définir la connexion pour utiliser l'authentification du système d'exploitation, mon serveur SQL local et un db existant dessus. J'ai défini LoginPrompt sur false. J'ai ajouté FDQuery1 au formulaire, ai fait la forme USE l'unité du datamodule, puis ai mis la connexion de FDQuery1 à celle du module de données et ajouté "select * from mytable" comme Sql. Ensuite, j'ai mis FDQuery1.Active à true dans l'OI. FDQuery1 ouvert sans plainte. J'ai réinitialisé FDQuery1.Active à false, sauvegardé le projet et l'ai fermé.
J'ai fermé Seattle, j'ai commencé à Tokyo et j'ai ouvert le projet. Lorsque j'ai défini FDQuery1.Active sur true, j'ai reçu exactement le même message d'exception que vous avez signalé. Fait intéressant, l'OI met ensuite à jour FDQuery1.Active pour afficher True.
J'ai ensuite défini FDQuery1.Active sur false puis sur true, et l'exception est et non. J'ai fermé et redémarré Tokyo, rouvert le projet et, encore une fois, la première fois (mais seulement la première fois) j'ai mis FDQuery1.Active à true, l'exception se produit à nouveau.
Nous vous invitons à inclure les étapes ci-dessus dans un rapport de problème à Emba. Btw, je n'ai pas passé de temps à enquêter sur le comportement d'exécution du projet. En supposant - et ce n'est qu'une supposition - il y a un problème quelque part dans l'EDI qui se manifeste quand il doit créer une instance du module de données pour que FDConnection puisse établir la connexion nécessaire pour ouvrir FDQuery1. Si c'est vrai, cela ne devrait pas affecter le comportement au moment de l'exécution, mais comme je l'ai dit, je n'ai pas enquêté là-dessus. Si j'ai raison, je pense que c'est plus un ennui qu'un problème majeur.
Mise à jour: Ce problème semble être spécifique à FMX. J'ai répété les étapes 1 à 3 dans un nouveau projet VCL Tokyo et le message d'exception + erreur ne se produit pas, même la première fois que FDQuery1.Active est défini sur true.
Mise à jour 2: Ce problème est facilement reproductible lors de l'exécution.Tout ce que vous devez faire est de supprimer le module de données des formulaires du projet | La liste AutoCreate, puis, au moment de l'exécution, tente d'ouvrir la FDQuery avant la création du datamodule. Évidemment, la solution consiste simplement à vérifier que le module datamodule existe avant d'ouvrir le FDQuery et, dans le cas contraire, à le créer dans le code. Btw, dans une application du monde réel, personnellement je ne compterais pas sur le paramètre de propriété Active d'un TDataSet dans l'EDI pour ouvrir l'ensemble de données, et l'ouvrirais toujours dans le code à la place. C'est une habitude dans les premières années de Delphi, où il semblait souvent y avoir des problèmes avec les paramètres de conception des datasets et sources de données qui se référaient à une connexion db ou similaire située dans un autre module "perdu" au moment de l'exécution.
Je sais que vous dites que cette erreur se produit au moment du design, mais que se passe-t-il si vous affectez le FDConnection du dm au FDQuery dans le code juste avant d'ouvrir la requête au moment de l'exécution? – MartynA
Faire ce que MartynA dit devrait fonctionner. Quoi qu'il en soit, si cela arrive également, c'est parce que le module de données n'est pas encore instancié, vous devez le créer dans le fichier dpr avant la création du formulaire. Si ce n'est que l'heure de conception, vérifiez que vous avez l'unité DM dans la liste uses, et essayez d'ouvrir la dfm du datamodule. vérifiez aussi si la connexion est active .. –