Discussion :

[GrPtj]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[pprem]

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 ?

[GrPtj]

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 ?

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 !

[SergioMaster]

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 !

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

[GrPtj]

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

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 ?

[GrPtj]

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 ?