Problèmes SQLQuery MySQL et Lazarus 1.4.4 FPC 2.6.4

Bonjour à tous,
Après avoir (enfin) réussi à réaliser correctement des écritures dans la BDD - nécessité de gérer le commit de la transaction depuis FPC 2.6.4-, me voilà face à un problème de rafraichissement de mes SQLQuery :
J'affiche un DBGrid, ou tout autre composant, pointant sur un datasource->SQLQuery. Tout va bien.
J'ouvre une fiche insérant un enregistrement dans la table. Je vérifie via MYSQL Workbench que l'enregistrement est bien inséré.
Retour sur ma fiche principale. Le Query ne s'actualise pas, même avoir tout essayé : Close puis Open, Active:=false puis Active:=true, réécriture SQLQuery.SQL, ExecSQL, Refresh...
SQLQuery.RecordCount ne s'incrémente pas.
Après la sortie, puis le retour dans l'application, les modifications apparaissent bien.
Quelqu'un aurait-il une idée ?
Merci

Ok, Je pense avoir compris mon erreur. Il s'agit encore d'un problème philosophique de Transaction. J'utilisais 2 Transactions différentes sur les fiches. Il semblerait qu'il faille utiliser la même... Certainement dû à des données en cache dans les composants.
Cela m'amène à une autre question : Dans une application, doit-on n'utiliser qu'un couple SQLConnection-SQLTransaction pour l'ensemble des fiches ?

Bonjour,
(selon ma compréhension au transactions ;))

1/Tout d'abord je favorise le type read-committed pour une transaction, car il est le type (à mon avis) le plus pratique.
-copier isc_tpb_read_committed dans le 'Dialogue d'éditeur de chaînes' (SQLTransactionx/params).
ou: SQLTransactionx.Params.Add('isc_tpb_read_committed') ;

2/ Si vous avez n SqlQuery reliées à n SqlTransactions, et à une seule source de données(Table1), et que une fois l'une de ces
transactions fait une modification, alors les autres ne voient les MAJ qu'après leurs fermetures et leurs ouvertures par:

SqlTransactionx.commit; // fermeture automatique de la transaction.
SqlQueryx.active:=True; //ouverture automatique de la transaction;

et non ça:
SqlQueryx.close; // car ici la transaction ne se ferme pas.
SqlQueryx.open;

Donc le code serait:

Code:

---

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

procedure TForm1.SqlQuery1AfterPost(DataSet: TDataSet); begin SqlQuery1.ApplyUpdates ; SQLTransaction1.Commit ; SqlQuery1.Active:=True ;   SQLTransaction2.Commit ; SqlQuery2.Active:=True ; . . SQLTransactionN.Commit ; SqlQueryN.Active:=True ; end;

---

3/Attribuer toutes les SqlQueries à une même transaction marche pour un seul utilisateur, mais il n'est pas adapté au mode réseau,
parce que si tu fais la mise à jour à cette transaction, toutes les SqlQueries se ferment automatiquement.

merci.

Ok,
Merci pour cette réponse complète. Je ne connaissais pas 'isc_tpb_read_committed'.
J'imaginais naïvement que la gestion des transactions ne s'appliquait qu'à l'écriture des données, et non à la lecture.
J'ai trouvé une solution qui consiste à exécuter un SQLTransactionx.CommitRetaining pour rafraichir les SQLQuery associées. Ce n'est peut-être pas très orthodoxe, mais ça fonctionne.
Merci pour votre aide.

Bonsoir,
Tu as tout à fait raison, SQLTransactionx.CommitRetaining fait un rafraîchissement sans fermer le SQLQuery!!
je l'utiliserai prochainement. ;)

Bonne continuation.
merci.

Heureux d'avoir pu - pour une fois - donner une info utile !:D

Bonjour, :P

Je viens juste de tester aujourd'hui une application, contenant une cinquantaine de SqlQueries, reliées à une seule transaction (type:read committed),
pour deux modes différents (mono-poste et réseau) en utilisant ce code:

Code:

---

1 2 3 4 5 6

procedure TForm1.SqlQuery1AfterPost(DataSet: TDataSet); begin SqlQuery1.ApplyUpdates ; SQLTransaction1.CommitRetaining; end;

---

et quelle était grande ma surprise!
Une seule transaction par application a suffit pour gérer et rafraîchir les données même en mode réseau (en ajoutant un trigger bien sûr).
et ça m'a permet de corriger mes idées. :D

merci beaucoup.

Bonjour,
Perso, j'ai quand même un peu de mal à comprendre l'intérêt des transactions, même après avoir lu les articles du site -très bien faits du reste - sur ce sujet.
Bien sur, cela permet de revenir en arrière en cas de défaut matériel ou d'erreur. Mais il me semble que si une application insère un enregistrement puis attend que l'opérateur soit ressorti de son application pour mettre à jour la Bdd, il y a risque qu'un autre client (en multiposte) essaie d'effectuer une écriture entre deux, provoquant un risque de duplication de clé...
Je me trompe ?
Perso, je n'utilise même pas SqlQuery1AfterPost ni ApplyUpdates ...
Je ne dois pas être bien bon, mais je suis autodidacte...;)
Désolé si l'on s'éloigne de l'axe purement Lazarus...

Bonsoir à tous,

Une transaction pourquoi faire?

1/ La transaction est une fonctionnalité associé à un ou plusieurs Datasets(ensembles de données: Tables, sqlQueries..) en vue de manipuler les données
dans ces derniers.

2/ En fait la transaction représente les mains et les yeux d'un ensemble de données et sans elle ce dernier n'est qu'un corps sans esprit, une machine en panne.

3/ Avant, quand il n'existait que des applications monoposte, la transaction était intégrée à son ensemble de données, un seul ensemble de données par
transaction, ce mécanisme était suffisamment fiable, pour mettre à jour un ensemble de données, parce que le serveur de base de données était local
(ex: le BDE) et donc la MAJ sur une même machine, était évidente et sans contraintes .

4/ Cependant avec la propagation des applications multipostes, ce mécanisme est dépassé pourquoi?
Parce que le support réseau est plus exigent:

Premièrement: le serveur de BDD est éloigné, et donc le trajet est incertain, déconnexions, surcharges, coupures de courant etc...
ce mécanisme, (un ensemble de données par transaction) n'est plus sûr, évidemment, envisageant cet exemple:

La BDD d'une entreprise comporte deux tables VENTES et STOCK, évidemment La quantité d'un article augmente de n dans la Table VENTES et doit
diminuer de n dans la table STOCK. maintenant on fait une MAJ, supposant que la transaction de la table VENTES passe et après, une panne
quelconque arrive la transaction de la table STOCK ne passe pas, donc cette valeur n'est pas ôtée de la table STOCK, alors que dans la table
VENTES est bien mentionnée!! ( incohérence des données).

Donc il faut développer un autre mécanisme, et ce dernier est d'attribuer une seule transaction à ces ensembles de données interdépendants
en vue de les atomiser dans un seul bloque, et pour y faire, la transaction doit être séparée de l'ensemble de données. Ainsi les mises à jour
vont être réaliser toutes, ou annulées toutes et restaurer les valeurs initiales.

Deuxièmement: le serveur de BDD dispose maintenant de plusieurs threads(utilisateurs), et donc comment les données passent-elles d'un thread à l'autre?
c-à-d une fois les données sont enregistrées dans la table VENTES, comment passent-elles dans les autres tables clones (VENTES1, VENTES2, VENTES3...)
appartenant à des threads différents (utilisateur2, utilisateur3, utilisateur4...) ?

L'opération passe en deux étapes:

L'étape 1: écriture des données dans le support physique(Table), se fait à l'aide de Commit ou CommitRetaining par une transaction.

L'étape 2: lecture des données par les transactions appartenant à d'autres threads, et cette lecture se fait selon les préférences des utilisateurs et donc
le paramétrage de la transaction.

Ex1: Transaction type SNAPSHOT(photo instantanée): elle est isolée, est donc ne voit rien des changements faits par les autres transactions.

Ex2: Transaction type READ COMMITED(Lis ce qui a été enregistré!): bien sûr elle voit les changements faits par d'autres transactions et une fois le refresh
est exécuté la transaction intègre les changements, mais dans ce cas ce n'est pas la transaction qui n'est pas au courante, mais c'est l'utilisateur.

On va remédier à ce problème par l'utilisation des déclencheurs(triggers) qui vont informer l'utilisateur de tous changements faits dans la BDD et ainsi
se fera le rafraîchissement des données.

Troisièmement: comment insérer des valeurs entières dans un champ clé primaire sans risque de faire un doublon?
et ben c'est très simple, on va les insérer au niveau de serveur de BDD en utilisant un GENERATOR et un TRIGGER.

enfin ce n'est qu'un abrégé. ;)

merci.

Bonjour,
Heureusement que ce n'est qu'un abrégé !!8O8O
Je vais essayer de digérer tout ça et creuser GENERATOR et un TRIGGER... même si je suis en monoposte local...
Merci encore.