[FIREDAC][SQLite] Petits problèmes à la suppression et à la lecture des données

Bonjour, je suis entrain de m'exercer pour apprendre la gestion d'un BDD. Voila la structure de mon application test

Pièce jointe 426100

Pour créer ma table j'ai utilisé FDQueryCreateTable avec la commande SQL :

Code:

---

1 2 3 4 5 6 7 8

CREATE TABLE IF NOT EXISTS tbl_categories ( id INTEGER PRIMARY KEY AUTOINCREMENT, left_id SMALLINT UNSIGNED NOT NULL, right_id SMALLINT UNSIGNED NOT NULL, level SMALLINT UNSIGNED NOT NULL, title VARCHAR(65) NOT NULL, description VARCHAR(150) NOT NULL );

---

Puis clic droit et exécuter. Jusque la pas de soucis

Pour insérer des données, le code SQL suivant :

INSERT INTO tbl_categories (title, description, level, left_id, right_id) VALUES (:Title, :Description, :Level, :Left_id, :Right_id)Associer au bouton ajouter

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

procedure TfrmPrincipale.btnInsertClick(Sender: TObject); begin With FDQueryInsert do begin ParamByName('Title').AsString := Edit1.Text; ParamByName('Description').AsString := Edit2.Text; ParamByName('Level').AsInteger := 0; ParamByName('Left_id').AsInteger := 1; ParamByName('Right_id').AsInteger := 2; ExecSQL(); end; FDQuerySelect.Close(); FDQuerySelect.Open; end;

---

jusque là ca va

Pièce jointe 426104

Par contre lorsque je clic sur le bouton supprimer du BindNavigator
1) L'item supprimé est toujours le premier de la liste et ce quelque soit celui qui est sélectionné dans le listview
2) L'affichage du Listview n'est pas automatiquement mise à jour. (Même en cliquant sur le bouton refresh du BindNavigator)

Je dois quitter et redémarrer l'application pour visualiser les changements

Ensuite, la suppression n'est pas toujours prise en compte (comme sur la capture suivante Test 2, n'a pas été supprimé par exemple).
Ensuite je ne sais pas pourquoi, d'un coup, les données ne veulent plus s'afficher alors que ma connexion est bien active et que le fichier est présent.

Pièce jointe 426106

Pièce jointe 426107


Note : Pour le Binding, j'ai utilisé l'assistant. Dans les options de connexion j'ai la persistance des données active

Ma question est donc qu'est ce j'ai oublié de faire ??? Je n'arrive pas à comprendre ce qu'il me manque.

Merci d'avance

Bon dimanche

Bonjour (ou plutôt re)

Ta liste n'est pas synchronisée (synch <-> * ton bindsourceDB)
C'est, à mon avis la cause de tes divers problèmes

Attention : A ma souvenance lorsque tu vas faire cette liaison tu risques d'avoir un message te disant qu'il va écraser tes anciens liens, accepte puis vérifie

Merci Serge

Pièce jointe 426115

La suppression fonctionne maintenant et le ListView se synchronise. Mais au lancement de l'application le ListView reste vide. :weird:

Pièce jointe 426118

Le BindNavigator ne s'active que lorsque je rajoute un nouvel élément et là Les données s'affichent :aie:

Pièce jointe 426122

Ce qui est bizarre c'est qu'avec un autre test et une connexion MySql je n'ai pas rencontré ces soucis. Je vais comparer pour voir. Et je vais (re)lire quelques PDF que j'ai sous le coude.
Je pense que je vais recommencer depuis le début, point par point cet après midi.

Merci

Bon appétit :zoubi:

Bonjour

Avec le bon lien entre TListView, TFDQuery et TBindNabvigator, tu ne devrais pas avoir ce soucis : la liste devrait el et bien se charger à l'ouverture de la table.

As-tu fais un peu de Pascal dans ton source ou tout via l'IDE ?

Citation:

---

Envoyé par BeanzMaster

La suppression fonctionne maintenant et le ListView se synchronise

---

c'est donc bien ce que je pensais

Citation:

---

Mais au lancement de l'application le ListView reste vide.

---

Vérifie que le autoactive est à true pour le lien (synchro)

Citation:

---

Je pense que je vais recommencer depuis le début, point par point cet après midi.

---

simplement supprimer les liaisons et les refaire en commençant par la synchronisation devrait le faire

cf aussi dans mon blog (LinkListControlToField1.Active:=True;)

Citation:

---

Bon appétit

---

Merci, c'est fait

Citation:

---

Envoyé par pprem

Bonjour

Avec le bon lien entre TListView, TFDQuery et TBindNabvigator, tu ne devrais pas avoir ce soucis : la liste devrait el et bien se charger à l'ouverture de la table.

As-tu fais un peu de Pascal dans ton source ou tout via l'IDE ?

---

Bonjour Patrick

Tout par l'assistant le seul bout de code c'est celui du bouton "btnInsert"

Citation:

---

Envoyé par SergioMaster

c'est donc bien ce que je pensais

Vérifie que le autoactive est à true pour le lien (synchro)

---

T'es le :king: effectivement la propriété "Active" de mon "FBQuerySelect" n'était pas activée. Vu que je suis passé par l'assistant LiveBinding je n'y ai pas prêté attention. Surtout c'est que ça a marché au début et d'un coup plus rien. Je me demande quel composant ou quelle manipulation j'ai faite pour que cela modifie cette propriété entre deux.

Il va falloir que je sois plus à l'affût de ce genre de petites choses.

Merci encore :ccool:

Bonjour,

Citation:

---

la propriété "Active" de mon "FBQuerySelect" n'était pas activée

---

je n'y avais pas vraiment fait allusion bien que j'y avais pensé cela me semblait trop évident.

Citation:

---

Je me demande quel composant ou quelle manipulation j'ai faite pour que cela modifie cette propriété entre deux.

---

tu as du avoir le message quand tu as mis en synchronisation ta liste ? c'est certainement là qu'il y a pu y avoir désactivation de ta table il faudrait vérifier cette hypothèse

je n'avais fait que répondre à la problèmatique LiveBindings maintenant il y a autre chose qui me "choque" ou plus exactement que tu peux améliorer.
Tu utilises deux querys pour tes données , plus un rafraichissement dans ta partie code, il y a mieux et plus facile
- Tu modifies le FDQuerySelect SELECT id,title, description, level, left_id, right_id FROM TBL_categories (on aura besoin de la colonne id)
- tu ajoutes un FDUpdateSQL
- Tu renseignes la propriété UpdateObject de FDQuerySelect avec FDUpdateSQL1
- double clic ensuite sur le FDUpdateSQL et génère les commandes (sachant qu'ensuite tu peux modifier ces commandes de façon plus "personnelle")
- ensuite plutôt que programmer le btnInsert , tu utilises l'évènement OnNewRecord pour initialiser les colonnes , donc plus besoin du bouton [Ajouter] le plus du bindnavigator suffit avec le bouton de validation pour confirmer ou non la saisie

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procedure TForm23.FDQuery1NewRecord(DataSet: TDataSet); begin // plusieurs écoles pour cette partie Dataset.FieldByName('Level').AsInteger := 0; Dataset.FieldByName('Left_id').AsInteger := 1; Dataset.FieldByName('Right_id').AsInteger := 2;   // ou FdQuery1.FieldByName('Level') // ou Dataset['level'] end;

---

maintenant, si tu tiens à passer par une requête Insert libre à toi mais avec le composant FDUpdateSQL tu as tout loisir d'utiliser les "commandes de table"
FDQuery1. Edit, Post, Insert ou Append, Delete

En fait, FDTable agit comme cela (sauf que c'est plus "figé"), un FDTable n'est qu'une requête SELECT * FROM et génére les SQL comme le générateur (image) le fait (bon cela dépend aussi de petites options upWhereKeyOnly, upWhereAll etc..). Dans un cas "simple" comme ce que tu nous montres le FDTable est tout aussi utilisable. Le couple FDQUery+FDUpdateTable (c'est valable aussi pour BDE, ZEOSDBO ...) est beaucoup plus intéressant dés que la Query est plus complexe (genre jointures de tables).

Seule chose que je n'ai pas encore essayé avec Firedac (et qu'il semble possible de faire) une requête avec plusieurs commandes SQL

Dernière chose, dans ton code pour le bouton [Ajouter]
tu fais un refresh de la requête

Code:

---

1 2	FDQuerySelect.Close(); FDQuerySelect.Open;

---

hypothèse à vérifier : mon "astuce" sur le lien LinkListControlToField1
Avant la commande d'insertion tu mets LinkListControlToField1.Active:=False;(un équivalent à la commande VCL Query1.DisableControls mais uniquement pour le lien)

[Edit] Au temps pour cette hypothèse, après essais, l'ensemble de données n'est pas rafraichi.
En faisant les tests, un petit truc m'énervai : le bouton [+] du Navigateur génére un Insert et du coup, la nouvelle ligne se trouve au dessus de la ligne en cours, j'ai changer le comportement avec ce code

Code:

---

1 2 3 4

procedure TForm23.BindNavigator1Click(Sender: TObject; Button: TNavigateButton); begin if Button=TNavigateButton.nbInsert then FDQuery1.Append; end;

---

le code du bouton [Ajouter], je l'ai fait ainsi

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

procedure TForm23.BtnInsertSQLClick(Sender: TObject); begin with TFDQuery.Create(self) do begin Connection:=FDConnectionSQlite; SQL.Text:='INSERT INTO tbl_categories (title, description,'+ ' level, left_id, right_id) VALUES ('+QuotedStr('Insert')+ ','+QuotedStr('Description')+',0,0,1)'; ExecSQL; end; // FDQuery1.Active:=False; // FDQuery1.Active:=True; FDQuery1.Refresh; // remplace les deux instructions FDQuery1.Last; // se positionne sur l'enregistrement ajouté end;

---

Bonjour,

Citation:

---

Envoyé par SergioMaster

Bonjour,


je n'y avais pas vraiment fait allusion bien que j'y avais pensé cela me semblait trop évident.

tu as du avoir le message quand tu as mis en synchronisation ta liste ? c'est certainement là qu'il y a pu y avoir désactivation de ta table il faudrait vérifier cette hypothèse

---

Le non affichage des données, c'était déja produit avant cette manipulation.

Citation:

---

Envoyé par SergioMaster

je n'avais fait que répondre à la problèmatique LiveBindings maintenant il y a autre chose qui me "choque" ou plus exactement que tu peux améliorer.
Tu utilises deux querys pour tes données , plus un rafraichissement dans ta partie code, il y a mieux et plus facile
- Tu modifies le FDQuerySelect SELECT id,title, description, level, left_id, right_id FROM TBL_categories (on aura besoin de la colonne id)
- tu ajoutes un FDUpdateSQL
- Tu renseignes la propriété UpdateObject de FDQuerySelect avec FDUpdateSQL1
- double clic ensuite sur le FDUpdateSQL et génère les commandes (sachant qu'ensuite tu peux modifier ces commandes de façon plus "personnelle")
- ensuite plutôt que programmer le btnInsert , tu utilises l'évènement OnNewRecord pour initialiser les colonnes , donc plus besoin du bouton [Ajouter] le plus du bindnavigator suffit avec le bouton de validation pour confirmer ou non la saisie

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procedure TForm23.FDQuery1NewRecord(DataSet: TDataSet); begin // plusieurs écoles pour cette partie Dataset.FieldByName('Level').AsInteger := 0; Dataset.FieldByName('Left_id').AsInteger := 1; Dataset.FieldByName('Right_id').AsInteger := 2;   // ou FdQuery1.FieldByName('Level') // ou Dataset['level'] end;

---

maintenant, si tu tiens à passer par une requête Insert libre à toi mais avec le composant FDUpdateSQL tu as tout loisir d'utiliser les "commandes de table"
FDQuery1. Edit, Post, Insert ou Append, Delete

En fait, FDTable agit comme cela (sauf que c'est plus "figé"), un FDTable n'est qu'une requête SELECT * FROM et génére les SQL comme le générateur (image) le fait (bon cela dépend aussi de petites options upWhereKeyOnly, upWhereAll etc..). Dans un cas "simple" comme ce que tu nous montres le FDTable est tout aussi utilisable. Le couple FDQUery+FDUpdateTable (c'est valable aussi pour BDE, ZEOSDBO ...) est beaucoup plus intéressant dés que la Query est plus complexe (genre jointures de tables).

Seule chose que je n'ai pas encore essayé avec Firedac (et qu'il semble possible de faire) une requête avec plusieurs commandes SQL

---

Je suis partie du tuto que l'on trouve dans le wiki de Delphi et de l'exemples sur la liste de taches présent dans le dossiers object pascal/samples. L'objet UpdateSQL va mettre vraiment utile, et juste par ton petit exemple j'arrive à entrevoir mieux les possibilité surtout pour les relations et c'est ce que je recherchai. Y-a-t-il une grande différence entre Post et Append ? Post insert à la fin et Append à l'endroit ou l'on est positionné, c'est bien ça ?

Citation:

---

Envoyé par SergioMaster

Dernière chose, dans ton code pour le bouton [Ajouter]
tu fais un refresh de la requête

Code:

---

1 2	FDQuerySelect.Close(); FDQuerySelect.Open;

---

hypothèse à vérifier : mon "astuce" sur le lien LinkListControlToField1
Avant la commande d'insertion tu mets LinkListControlToField1.Active:=False;(un équivalent à la commande VCL Query1.DisableControls mais uniquement pour le lien)

[Edit] Au temps pour cette hypothèse, après essais, l'ensemble de données n'est pas rafraichi.
En faisant les tests, un petit truc m'énervai : le bouton [+] du Navigateur génére un Insert et du coup, la nouvelle ligne se trouve au dessus de la ligne en cours, j'ai changer le comportement avec ce code

Code:

---

1 2 3 4

procedure TForm23.BindNavigator1Click(Sender: TObject; Button: TNavigateButton); begin if Button=TNavigateButton.nbInsert then FDQuery1.Append; end;

---

le code du bouton [Ajouter], je l'ai fait ainsi

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

procedure TForm23.BtnInsertSQLClick(Sender: TObject); begin with TFDQuery.Create(self) do begin Connection:=FDConnectionSQlite; SQL.Text:='INSERT INTO tbl_categories (title, description,'+ ' level, left_id, right_id) VALUES ('+QuotedStr('Insert')+ ','+QuotedStr('Description')+',0,0,1)'; ExecSQL; end; // FDQuery1.Active:=False; // FDQuery1.Active:=True; FDQuery1.Refresh; // remplace les deux instructions FDQuery1.Last; // se positionne sur l'enregistrement ajouté end;

---

---

Tout ça c'est vraiment nickel, je te remercie car dans tous les tutos ou documents que j'ai à ma disposition aucun ne montre cette façon de faire. Tous les exemples que j'ai pu trouver se contente de table simple sans relations et utilisent plusieurs FDQuery, ou utilises les données de démos existante fournis avec Delphi. Rien depuis le débuts mis à part de petit de codes que l'on ne sait pas trop comment les intégrés. Les exemples que j'ai pu trouver sont souvent par très explicites et rarement avec l'utilisation conjointe du LiveBinding.

Merci pour tes astuces, qui me montre les possibilités avec et sans BindNavigator. Je vais pouvoir approfondir mon test sur cette table de catégories intervallaires. Par rapport à mon code PHP ou je gère mes table grâce à un ORM et un pattern MVC maison, il y a beaucoup de différences. La marche à suivre demande un peu plus de réflexion.

Petite question sur l'organisation. Dans le cas ou nous avons plusieurs tables. Je pensais créer un DataModule commun pour la connexion à la BDD et une unité par table, avec une classe, (ex TFDCategoriesManager) et y adjoindre les méthodes CRUD et autres méthodes utiles comme getChilds, getParent. Est-ce une bonne solution ? Du coup si j'ai bien tout compris, pour le LiveBinding il faudra que je lie tout ça par code dans ce cas.

Merci encore, je vais faire quelques tests en suivant tes recommandations et essayer de trouver une approche qui me convienne.

Bonne journée :ccool:

Citation:

---

Envoyé par BeanzMaster

Le non affichage des données, c'était déja produit avant cette manipulation.

---

peut-être as-tu changé ou simplement vérifié le SQL (cela peut désactiver)

Citation:

---

Y-a-t-il une grande différence entre Post et Append ?

---

Bon je pense que tu voulais écrire INSERT et APPEND
POST à l'endroit où on est positionné
APPEND en fin de table

Citation:

---

je te remercie car dans tous les tutos ou documents que j'ai à ma disposition aucun ne montre cette façon de faire

---

c'est bien la peine que je me décarcasse dirait Ducros !
C'est vrai que dans mes tutoriels je n'ai pas abordé l'édition des données mais parce que pour moi Query+UpdateSQL ça date déjà de BDE :roll:

Citation:

---

Les exemples que j'ai pu trouver sont souvent par très explicites et rarement avec l'utilisation conjointe du LiveBinding.

---

Parce que la bibliothèque de LiveBindings est très méconnue. La seule chose que je n'ai pas encore réussie à faire c'est de lier deux requêtes avec paramètres pour la deuxième sans m'affranchir du TDataSource avec les Livebindings, j'ai quelques pistes mais pas de temps actuellement.

Citation:

---

Petite question sur l'organisation. Dans le cas ou nous avons plusieurs tables. Je pensais créer un DataModule commun pour la connexion à la BDD

---

OUI, bonne pensée :ccool:

Citation:

---

une unité par table

---

là ça dépend beaucoup il peut très bien y avoir des tables maitre/détail/... donc pas forcément une seule table par unité

Code:

---

1 2 3

avec une classe, (ex TFDCategoriesManager) et y adjoindre les méthodes CRUD et autres méthodes utiles comme getChilds, getParent. Est-ce une bonne solution ?

---

tel que la structure de ta table le suggère OUI SQLite étant limité par rapport à d'autres SGBD où une grande partie pourrait être géré par triggers

Citation:

---

Du coup si j'ai bien tout compris, pour le LiveBinding il faudra que je lie tout ça par code dans ce cas.

---

Je ne suis pas très sûr, car je ne vois pas bien le sujet. Mais sache que l'on peut très bien faire du livebindings sur de purs objets.

Par exemple : TProtypeBindSource permet très facilement (créer et lié un ensemble d'objets sans bases de données) le titre est peut être mauvais au niveau du tuto et TProtypeBindSource est en fait un mix d'au moins deux composants (TAdapterBindSource, TDataGeneratorAdapter)

Bonjour

Merci, Serge pour toutes ces explications je vais creuser tout ça. Il me faut juste un peu de temps pour cerner la méthodologie à adopter. J'ai très peu utiliser les systèmes de BDD en pascal en général et mon dernier "gros projet" était une application de gestion de vidéocassettes, qui date de quelques années avec BDE :oops:

Bonne fin de soirée

Bonjour,

je n'ai pas trop compris où tu voulais aller avec ton projet et ta BDD mais au vu de la structure que tu avais indiqué et ceci

Citation:

---

cette table de catégories intervallaires.

---

Je pense que tu devrais lire le papier de Frédéric Brouard aka SQLPro arborescence
Je ne sais si cela peut s'appliquer avec SQLite puisqu'il y a des procédures et que SQLite, bien que possédant au moins certaines formes de procédures stockées ;) @tourlourou, risque de faire sa mauvaise tête sur celles-ci

En tout cas, entre Paradox et SQLite c'est déjà un grand pas (dommage que Firebird ou PostGresSQL ne tourne pas sous Androïd, reste Interbase)

Bonjour,

J'ai plusieurs projets que je souhaites réaliser avec les BDD. Comme je l'avais dis, je dispose d'un framework PHP avec un système d'ORM qui me simplifie grandement la vie, pour gérer les tables de ma BDD et les relations entre celles-ci (j'ai juste à déclarer les champs de ma table et initialiser mes relations dans le "constructor". Dans mes modèles j'ai accès à une sorte de "wrapper" avec quelques fonctions genre Find(arguments) qui se charge de construire mes requêtes SQL en fonction des paramètres passés et qui me retourne les résultats sous forme de liste d'objets. Au final j'ai juste à ajouter mes fonctions de Creation, Update et Delete adéquates dans le contrôleur en fonction de la table. C'est donc une démarche très différente comparer à Delphi et très rapide à mettre en place

Mon but est de réaliser dans un premier temps un mini backend avec Delphi pour mes tables avec MySql.
Ici j'ai choisi SQLite pour mes tests sachant qu'au niveau SQL, il y a des petites différences avec MySql.

Ce que je veux c'est d'abord comprendre la méthodologie et les mécanismes de la gestion de BDD avec Delphi.
Je sais qu'il existe des solutions ORM Delphi, mais les utiliser sans comprendre ce qui ce passe derrière ne m'intéresse pas vraiment.
Ma table de catégories intervallaire, n'est qu'un exemple de table parmi d'autre. J'ai choisi de commencer par cette table car je l'utilise énormément. De plus par exemple pour l'ajout d'un item elle nécessite de trouver les bornes par rapport à autres items présents. Ce qui pour moi représente un bon exercice à la fois simple et "complexe" pour triturer les composants de Delphi et comprendre "comment ça marche". Une fois cela assimilé je passerai aux relations et aux agrégats.

Une des choses que je n'arrives pas encore à saisir c'est quand doit-ont utiliser une FDTable, un TDataSource sachant qu'un FDQuery suffit pour renvoyé les résultats voulus et effectuer les opérations.
Dois-je utilisé un FDQuery ou je définirais tous les champs de la table en designtime ? et le coupler comme tu me l'as suggéré à un FDUpdateSQL pour les opérations d'Insert/Update et de suppression ? Dans le cas ou je voudrais récupérer seulement une partie des champs donc un "Select" dois-je utilisé un autre FDQuery créer en runtime ? ou un autre FDQuery disponible dans le datamodule par exemple ? D'ou mon idée de créer une Classe par table pour simuler un genre d'ORM.

Dans tous les documents et videos que j'ai pu trouver sur le web ou des livres que je dispose "Delphi Cookbook, Delphi expert...." tous les exemples sont très sommaire (une liste de taches, une liste de course...) ou reprennent les BDD de demos disponibles avec Delphi, mais toujours de façon sommaire sans réelles explications pour bien comprendre les implications et imbrications : Tu poses le composant, t'écris ce bout code et voila, ok c'est bien mais quid ????? J'ai beaucoup de mal à comprendre avec cette méthode d'écriture de tutoriel dans le cas présent .

Il y a bien des informations par ci par là mais rien de réellement concret et complet. (Et les plus vieux tutos avec BDE, pas vraiment utiles avec FireDAC qui à une philosophie un peu différente, surtout couplé avec les LiveBindings).

A force de tester je vais bien arriver à un compromis et une méthodologie que je comprendrais. Déja, je vais me commander le livre de Cary Jensen, je commencerai surement à y voir plus clair. Enfin j'espère.

Bonne journée

Bonjour,

pour répondre à quand utiliser FDTable, quand utiliser FDQuery et quand utiliser UpdateSQL en schématisant un peu

FDTable est l'équivalent d'un FDQuery avec SELECT * FROM TABLE + un FDUpdateSQL (les commandes étant construites en fonction des options upwhereKey, upwhereAll ou upWhereChanged comme pour le BDE)
Inconvénient de FDTable pas de jointure au sens strict du terme, on peut effectivement ajouter des champs calculés pour faire "office de jointure" (type lookup) mais il faut bien sûr adjoindre les autres tables pour faire les relations

FDQuery est en lecture seule, FDUpdateSQL est "l'ajout" qui permet de traiter FDQuery comme on le ferait avec Edit,Post,Insert, Update etc...
FDQuery contrairement a un FDTable peut également exécuter des commandes (ExecSQL).

Donc, (en vieillissant,) je préfère les FDQuery (même pour une table simple où je doit charger toutes les colonnes. Mais j'utilise aussi, de plus en plus des FDConnexion.ExecSQL pour les commandes

Citation:

---

Et les plus vieux tutos avec BDE, pas vraiment utiles avec FireDAC qui à une philosophie un peu différente

---

Firedac est quand même très BDE Like, ce qui a été écrit pour BDE reste en grande partie valable pour Firedac

Citation:

---

surtout couplé avec les LiveBindings

---

Rien à voir, Firedac fonctionne sans LiveBindings, c'est comme si tu écrivais Firedac couplé avec FMX
LiveBindings est une couche entre l'interface utilisateur et les données (ou objets), une sorte de velcro

Citation:

---

Déja, je vais me commander le livre de Cary Jensen, je commencerai surement à y voir plus clair.

---

sur ce que je viens d'écrire non, par contre il y a un somme d'informations sur Firedac un grosse Bible,pas une Bible complète (ie. rien sur FDBatchMove, je ne crois pas avoir lu quoique ce soit sur les maprules ou autres petites options) mais ça reste un must