Firedac, BatchMove, ajout d'un champ à la table de destination

Bonjour, grâce à votre aide j'utilise batchmove !
Je copie une table du serveur localement dans une MemTable.
Pour le travail en local j'ai besoin d'ajouter un champ à cette MemTable.
J'obtiens la MemTable avec son champ en plus et ses données .
Mais je fais 2 fois le batchmove.execute , je suppose qu'il y a un autre moyen de mettre à jour la Memtable ?

Code:

---

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

FDTbHistoCdc.Open() ; FDBatchMoveDataSetReader1.DataSet := FDTbHistoCdc ; FDBatchMoveDataSetWriter1.DataSet := FDMmMGCFC ; FDBatchMove1.Mode := dmAppendUpdate; try FDBatchMove1.Execute; except on E: EFDDBEngineException do ShowMessage('MySQLtoMem : ' + E.Message); end; FDTbHistoCdc.close ; //ajout champ TypeLgn with FDMmMGCFC.FieldDefs do with AddFieldDef do begin Name := 'TYPELGN' ; DataType := ftInteger ; end;

---

Code:

---

1 2 3 4

//update de la MemTable FDMmMGCFC.close ; FDMmMGCFC.Open ; FDBatchMove1.Execute;

---

J'ai essayé sans succès de remplacer les 3 dernières lignes par

Code:

---

1 2	FDMmMGCFC.ApplyUpdates() ; FDMmMGCFC.Refresh ;

---

Bonjour

Le TFDBatchMove copie la structure, les données ou les deux, mais normalement il écrase la destination avec ce qu'il doit envoyer (selon ses options d'écritures).

N'est-il pas possible d'ajouter le nouveau champ dans la requête d'origine ? Ce serait plus simple à gérer ensuite selon comment il sera alimenté.

Et d'ailleurs, pourquoi exécuter 2 fois le TFDBatchMove ? La première devrait suffire à alimenter la table en mémoire, non ?

Citation:

---

Et d'ailleurs, pourquoi exécuter 2 fois le TFDBatchMove ? La première devrait suffire à alimenter la table en mémoire, non ?

---

la première alimente bien la table en mémoire mais il faut fermer et rouvrir la table pour pouvoir utiliser le nouveau champ,
donc on perd les données, d'où le deuxième appel ...
Si le champ est crée avant le batchmove il y a une erreur : inadéquation entre les champs entre origine et destination.
Si je fais dans cet ordre il n'y a pas d'inadéquation ?

Citation:

---

N'est-il pas possible d'ajouter le nouveau champ dans la requête d'origine ? Ce serait plus simple à gérer ensuite selon comment il sera alimenté.

---

effectivement c'est une bonne idée !

Je présume que tout cela est la suite de ce post https://www.developpez.net/forums/d2...re-renumerote/
J'avoue que je n'en comprend toujours pas vraiment le but !

Citation:

---

Envoyé par pprem

N'est-il pas possible d'ajouter le nouveau champ dans la requête d'origine ?

---

j'approuve pleinement cette direction tout en déplorant que vous continuiez sur le Batchmove alors qu'une GTT Firebird serait plus rapide

Effectivement, c'est la suite de mes essais, j'ai préféré refaire une conversation pour clarifier ...

Citation:

---

une GTT Firebird serait plus rapide

---

Je croyais que passer par les MemTb au lieu de base sql était votre proposition ?
Pouvez vous préciser ?

Je viens de me renseigner sur les GTT : Global Temporary Tables
Si j'ai bien compris c'est l'équivalent des MemTable firedac.
Au lieu de créer une table FD locale, je crée une table globale firebird.
Du coup je ne passe plus par firedac, je copie directement ma table firebird dans la GTT ?
Je suppose qu'il y a des sql pour passer de la table à la GTT 'à la manière' d'unbatchMove ?

je ne comprends pas trop ce paramètre qui semble important :

Citation:

---

Global temporary tables have persistent metadata, but their contents are transaction-bound (the default) or connection-bound.

---

Actuellement avec les MemTb, le client charge les lignes necessaires du serveur et les modifie.
Ensuite je récupère les lignes modifiées avec le MemTb.delta et je retourne les modifications sur le serveur.
Avec une Global Temporary Table quelle serait la différence, à part dispenser d'utiliser firedac ?

Citation:

---

Envoyé par GrPtj

Je croyais que passer par les MemTb au lieu de base sql était votre proposition ?

---

la mienne, non je ne crois pas. C'est vous qui voulais passer par SQLite, moi je n'ai fait qu'indiquer de passer par un TBatchMove dans la problématique exposée.
J'ai indiqué qu'il fallait passer par SQLite dans le cas de postes déconnectés (comme par exemple des mobiles, qui de toute façon aurait du mal à se connecter à Firebird avec Firedac, sauf bidouillage en cours de test)

Citation:

---

Envoyé par GrPtj

Je viens de me renseigner sur les GTT : Global Temporary Tables

---

vraiment pas curieuse alors car je l'ai indiqué 2 fois :roll:

Citation:

---

Si j'ai bien compris c'est l'équivalent des MemTable firedac.

---

AMHA en mieux

Citation:

---

Au lieu de créer une table FD locale, je crée une table globale firebird.

---

non, la table GTT est créée une seule fois la structure est ensuite gardée

Citation:

---

Du coup je ne passe plus par firedac, je copie directement ma table firebird dans la GTT ?

---

ou plutôt une sélection de celle-ci

Citation:

---

Je suppose qu'il y a des sql pour passer de la table à la GTT 'à la manière' d'unbatchMove ?

---

mon dernier post indiquait les SQL à utiliser, sans structure de table il était difficile de proposer plus

Citation:

---

Envoyé par GrPtj

je ne comprends pas trop ce paramètre qui semble important :
Global temporary tables have persistent metadata, but their contents are transaction-bound (the default) or connection-bound.

---

Bien sûr qu'il est important !
ON COMMIT PRESERVE ROWS les données resteront le temps de la session soit, le même comportement que le fdmemtable la table ou plutôt les données de la session étant supprimées en fin de connexion. (Une session égal une connexion utilisateur, un utilisateur ne "voit" pas les données des autres sessions). Bien sûr on peut faire des delete des données dans la table.
ON COMMIT DELETE ROWS est plus compliqué, il faut parfaitement maitrisé les transactions dans ce cas

Et bien voila j'ai remis tous les morceaux dans l'ordre !!!
merci beaucoup

Du coup un conseil par rapport à transaction-bound ou connection-bound ?

Citation:

---

Envoyé par GrPtj

Actuellement avec les MemTb, le client charge les lignes necessaires du serveur et les modifie.

---

le simple INSERT INTO FROM SELECT FROM

Citation:

---

Ensuite je récupère les lignes modifiées avec le MemTb.delta et je retourne les modifications sur le serveur.

---

l'utilisation du UPDATE OR INSERT

Citation:

---

Avec une Global Temporary Table quelle serait la différence, à part dispenser d'utiliser firedac ?

---

réfléchissez à qui bosse et comment : le programme ou Firebird ?

Citation:

---

Envoyé par GrPtj

Du coup un conseil par rapport à transaction-bound ou connection-bound ?

---

Vous êtes très à l'aise avec les transactions ? Perso, malgré mes années d'expérience, je ne le suis toujours pas complètement. Avec Firedac c'est encore plus subtil, surtout que cette histoire de Delta ne vas pas arranger les choses AMHA c'est simplifiable

Merci beaucoup pour tous ces éclairages,
Je retiens que si on n'a pas besoin de travailler coupé du serveur les GTT sont préférables,
les MenTable de firedac permettent de travailler localement ou avec plusieurs sortes de bdd.

Citation:

---

Envoyé par GrPtj

les MemTable de firedac permettent de travailler localement ou avec plusieurs sortes de bdd.

---

ne pas confondre FDMemTable et FDLocalSQL on peut très bien faire des SQLs sur plusieurs sortes de BDD sans avoir besoin de tables mémoires

J'ai refait mes essais avec une GTT et c'est très concluant.
Cependant je voudrais créer les champs de la GTT à partir de ma table persistante sans avoir à les écrire un par un.
Y a-t-il une commande pour ça ?

Code:

---

1 2 3

CREATE GLOBAL TEMPORARY TABLE TEST select * from MATABLE ON COMMIT PRESERVE ROWS

---

ne fonctionne pas.

Bonjour,
Il me semble avoir lu de pprem qu'un BatchMove pouvait copier la structure seulement : serait-ce utilisable ici ?

je ne crois pas,
le batchmove copie entre 2 composants firedac
pas entre 2 tables firebird

Quid de ceci, inspiré d'ici ?

Code:

---

1 2 3 4

CREATE GLOBAL TEMPORARY TABLE TEST AS select * from MATABLE where 1=2 ON COMMIT PRESERVE ROWS;

---

Bonjour,

Une table GTT est une table dont la structure ne se crée qu'une seule fois (pour tous les utilisateurs), pas à chaque fois. Donc non il n'y a pas de Create à faire vous mélangez un code de céation àevec un code de remplissage.
A l'occasion vous pouvez créer/détruire une table GTT à partir d'un FDScript