[D10.3] Firedac Comment enregistrer dans la BDD le contenu d'un TFDMemTable

Bonjour à tous,

J'ai du mal avec TFDMemTable...
Je souhaite faire quelque chose de simple :

1- copier la structure d'une table dans un TFDMemTable (Mem) : mem.copydataset(query1,[costructure]); // Ok ça marche
2- j'ajoute des lignes dans ma table mémoire Mem : // pas de problème
3- je voudrais enregistrer dans la base le contenu de mon Mem. Là je coince, je ne vois pas comment faire. J'ai beau regarder la doc, je ne trouve pas !

C'est surement très simple ?

Merci d'avance de votre patience/indulgence.

Du coup si c'est pour faire un cache de données sur un TSQLQuery pourquoi ne pas utiliser TFDDataSet.CachedUpdates ?

Sinon à partir du TFDMemTable, tu peux le balayer et générer les UPDATE (voire INSERT) en SQL

Citation:

---

Envoyé par ShaiLeTroll

Du coup si c'est pour faire un cache de données sur un TSQLQuery pourquoi ne pas utiliser TFDDataSet.CachedUpdates ?

---

Ben, je me casse la tête (sans doute pour pas grand chose) pour une histoire de numéro de chrono en mutli-utilisateur ...

Citation:

---

Envoyé par ShaiLeTroll

Sinon à partir du TFDMemTable, tu peux le balayer et générer les UPDATE (voire INSERT) en SQL

---

Ah oui bien sur, mais j'imaginais qu'on pouvait tout enregistrer d'un coup avec un batchmove par exemple... mais non.

Je vais suivre ton conseil N°2.
Merci

Bonjour,

Avec un petit coup de FDLocalSQL peut-être ou encore un FDBatchmove
Dans le premier cas il faut mettre un FDConnection SQLite, FDLocalSQL, ajouter la table mémoire à la liste des tables (datasets du FDlocalSQL) et une requête sur la bdd
puis faire un INSERT INTO TABLE SELECT * FROM fdmemtable, en n'oubliant pas d'activer FDlocalSQL avant ;)

dans le deuxième cas il faut un fdbatchmove, un fdDatasetReader, un fdDatasetWriter

Citation:

---

Envoyé par zarbouine

Ben, je me casse la tête (sans doute pour pas grand chose) pour une histoire de numéro de chrono en mutli-utilisateur ...

---

Perso, j'y connais rien en FireDAC, je suis en ADO et avant j'étais en Devart, le BatchMove ça doit être une bonne approche
Ayant écrit mon générateur deux générateurs de SQL (MySQL, Oracle) à base de TClientDataSet (et son Delta), j'ai l'habitude de faire comme ça car j'aime savoir ce que mon programme produit comme SQL

Sinon, je ne sais pas ce que c'est ce Chrono mais une SEQUENCE, TRIGGER, TRANSACTION, il y a plein de moyen pour résoudre un membre problème, chrono comme chronologie soit juste un compteur, ou chrono comme chronomètre soit du temps

Citation:

---

Envoyé par SergioMaster

Bonjour,

dans le deuxième cas il faut un fdbatchmove, un fdDatasetReader, un fdDatasetWriter

---

ça j'ai essayé, et curieusement ça ne marche pas, sans planter, mais pas de mise à jour. (je n'ai pas creusé plus avant, supposant que ce n'était pas adapté à une table mémoire)

Citation:

---

Sinon, je ne sais pas ce que c'est ce Chrono mais une SEQUENCE, TRIGGER, TRANSACTION, il y a plein de moyen pour résoudre un membre problème, chrono comme chronologie soit juste un compteur, ou chrono comme chronomètre soit du temps

---

je m'explique un peu mieux : ce chrono c'est un n° de commande (PK autoinc), et ce que je voulais éviter c'est une rupture dans ce n° si deux utilisateurs créent une commande " en même temps" et que le premier abandonne sans valider. Je suppose alors que le N° du premier est perdu (à moins que le BDD bouche les trous, je n'ai pas essayé)

Bonjour

Citation:

---

Envoyé par zarbouine

ça j'ai essayé, et curieusement ça ne marche pas, sans planter, mais pas de mise à jour. (je n'ai pas creusé plus avant, supposant que ce n'était pas adapté à une table mémoire)

---

AMHA, Il n'y a aucune raison qu'une table mémoire ne puisse être utilisée.
Il eusse fallu changer dans les propriétés de FDBatchmove la valeur MaxErrors (ce qui a fait le "sans planter") et activer le log
puis regarder le fichier log obtenu pour voir où ça coince.

Citation:

---

Envoyé par zarbouine

...c'est un n° de commande (PK autoinc),

---

Je laisserais la AutoInc faire son boulot et je ne l'utiliserais pas comme identifiant externe, peu importe les trous qui ne seront jamais bouché effectivement

deux façon de faire

Via Delphi, une SEQUENCE dédiée, utiliser pour générer le numéro de commande au moment de la validation, celle ou l'on ne peut plus annuler

Via un Trigger, je ferais le calcul du numéro de commande continu (un autre champ unique dans la table) et via un RETURNING, tu récupères la valeur insérée
Cela permet que cela soit la base qui gère cela sans risque de collision avec une SEQUENCE qui n'est utilisé qu'au moment final


Dans ces deux façons, c'est bien un champ dédié au n° de commande, non technique, calculé au moment opportun.
Pense si un jour la règle change, on te demande un nuémro de commande daté genre YYYYMMCCC, tu n'as qu'a changer le moteur de calcul du numéro, tout le reste tout la partie intégrité PK-FK n'est pas impacté

Tout ça manque surement de TRANSACTION COMMIT et ROLLBACK aussi pour se poser ce genre de problématique, ah oui en même temps, on y pense quand on gère soit même le SQL mais on l'oublie vite quand FireDAC fait tout.


Mais bon tout ça me semble étrange ... je pense que l'insertion est faite dès le début du process de création de commande, cela modifie le dataSet puis ça envoie
Et ça c'est justement ce que je ne fais jamais, j'utilise des objets business, tout est fait en mémoire et à la fin ça génère le SQL et envoie tout d'un en TRANSACTION

et donc finaklement un CacheUpdates fait la même chose même si je préfère de loin faire ça moi même, c'est la seule chose intéressante dans l'informatique de gestion alors si on enlève ça, quel ennui.

Citation:

---

Envoyé par ShaiLeTroll

Je laisserais la AutoInc faire son boulot et je ne l'utiliserais pas comme identifiant externe, peu importe les trous qui ne seront jamais bouché effectivement

Dans ces deux façons, c'est bien un champ dédié au n° de commande, non technique, calculé au moment opportun.
Pense si un jour la règle change, on te demande un nuémro de commande daté genre YYYYMMCCC, tu n'as qu'a changer le moteur de calcul du numéro, tout le reste tout la partie intégrité PK-FK n'est pas impacté

.

---

Je n'avais pas pensé à ça ! mais oui c'est important de différencier PK-FK de la numérotation end-user ! :oops:
Très bon conseil !! Je me demande pourquoi je n'y ai pas pensé... manque de recul ! mais ça vient doucement, pas mal grâce aux conseils avisés.
Merci beaucoup !:D

Citation:

---

Envoyé par ShaiLeTroll

et donc finaklement un CacheUpdates fait la même chose même si je préfère de loin faire ça moi même, c'est la seule chose intéressante dans l'informatique de gestion alors si on enlève ça, quel ennui.

---

:mouarf: Je ne m'ennuie pas (encore) avec les CacheUpdates... ça viendra peut-être :lol: