Discussion :

[navyg]

Bonjour,

Encore un truc que je n'arrive pas à comprendre ...
L'application que j'ai migré (quasi redéveloppée) de paradox 5.0 à mariadb 10 depuis une delphi v3 vers une delphi 10.4 fonctionne très bien mais ... car il y a un mais ...
J'ai cherché sur le forum et sur le net en général et je n'ai pas vu ce problème évoqué.

En version 64bits, l'application fonctionne très bien. Dès que je valide une modification dans un enregistrement, elle se répercute immédiatement sur la base dès que je la rafraichis dans heidisql.
J'ai paramétré les bases pour que si un utilisateur rentre en édition dans un enregistrement, les autres postes qui cherchent à éditer le même enregistrement recoivent un message comme quoi il est verrouillé, et à mon grand étonnement ça a marché du premier coup. Bon, tout allait bien ...

Bien évidemment, selon la loi de l'emmerdement maximum, sur un des postes, bien qu'il soit en w10 64bits, la version 64 bits ne fonctionne pas avec un message d'erreur sur la dll qui n'est pas la bonne.
Pourtant j'utilise la même libmysql.dll que sur les deux autres postes, spécifique au 64 bits (je précise qu'il faut que j'utilise une libmysqll.dll du 17/07/2017, car les versions ultérieures que j'ai pu trouvé en 64bits provoquent également un message d'erreur, y compris la libmariadb.dll du 03/11/2021).
Qu'à cela ne tienne me dis-je, je vais installer la version 32 bits avec la dll 32bits.
Résultat, l'application se lance bien, plus de messages d'erreurs, je rentre en consultation sur toutes les tables sans problèmes.
Et puis par commodité car j'étais sur ce poste, je fais une modification sur un enregistrement pour vérifier le bon verrouillage de celui-ci.
Je rafraichis dans heidisql, la modification n'apparaît pas ... je rafraichis la table dans mon appli ... re heidisql ... rien ...
La modification semble bien appliquée dans la table, y compris avec un refresrecord, mais lorsque je ferme l'application et que je la réouvre, la modification précédente n'a pas été prise en compte, ce que semblait corroborer l'examen sous heidisql.
Après plusieurs tests et essais, je me suis rendu compte que la base était toujours à jour de l'avant dernière modification. Je m'explique ...
Le champ contient 1.
Je mets 2 dans le champ, je valide, rien ne se passe dans la base alors que dans l'application tout semble être bon, même après un refreshrecord.
Je mets 3 dans le champ, je valide, la base est mise à jour avec la valeur 2 ! alors que dans l'application, la valeur 3 apparaît même après un refreshrecord.
Je précise bien que ce comportement ne se passe qu'avec une version compilée en 32 bits alors que le même code compilé en 64 bits fonctionne très bien. ...

J'ai bien pensé à une histoire de cache ou un truc comme ça, mais malgré toutes les options que j'ai pu essayé sur la table en question (ou toute autre table après vérification) au niveau de UpdatesOption, rien n'y fait.
J'avoue que je ne vois plus comment résoudre ce problème malgré plusieurs journées de recherche ...

Quelqu'un a t il été confronté à un problème du genre ?

Merci par avance pour votre aide ...

[ShaiLeTroll]

En utilisant la version 32Bits, tu as reconstruit tout le projet en changeant la plateforme cible ?
Ne pas confondre l'OS hôte en 64Bits et l'application construite pour Win64 ou Win32\WOW64.
La DLL est où ? avec l'exe ou dans un répertoire pointé par le PATH ?

Fais-tu des Transactions explicites ou tout est en Auto-Commit ?
L'utilisation de la DLL est en directe ou via un provider ?

[navyg]

En utilisant la version 32Bits, tu as reconstruit tout le projet en changeant la plateforme cible ?
Ne pas confondre l'OS hôte en 64Bits et l'application construite pour Win64 ou Win32\WOW64.
La DLL est où ? avec l'exe ou dans un répertoire pointé par le PATH ?

Fais-tu des Transactions explicites ou tout est en Auto-Commit ?
L'utilisation de la DLL est en directe ou via un provider ?

Je viens juste de trouver, donc j'allais donner la réponse quand je vois tes questions.
D'abord, merci de t'intéresser à mon problème.
Oui je reconstruis tout le projet en changeant la plateforme cible dans embarcadero
Non non je ne confonds pas
La dll est dans le même répertoire que l'exe
J'ai essayé les deux types de transactions sans changement de résultat
La dll est en direct dans le même répertoire que l'appli et la base est sur le même réseau local.

En fait j'utilise une libmysql.dll que j'utilisais avec d'autres applications en 32 bits. cette version est datée du 18/03/2019 et elle fonctionnait avec mes autres programmes jusqu'à maintenant.

Ne sachant plus quoi faire, j'ai recherché d'autres versions de libmysql.dll dans mes vieux dossiers et j'en ai trouvé 2 en 32 bits du 12/06/2003 et du 21/05/2008.

Juste en utilisant celle du 21/05/2008, tout a refonctionné impeccablement ...

C'est assez empirique comme solution mais elle marche.

Cette difficulté à bien appairer les différentes versions de libmysql.dll avec les moteurs mysql est assez pénible, d'autant plus que ces dll sont assez difficiles à trouver en direct ou alors provenant de sources que l'on pourrait qualifier de douteuses.
Je ne comprends pas pourquoi les promotteurs de mysql/mariadb ne mettent pas ces dll en téléchargement direct et gratuit plutôt que perdues dans des installations complètes, d'autant plus que les dernières versions ne fonctionnent pas le plus souvent !!!
La preuve, il a fallu que je retrouve des vieilles versions, que ce soit en 64 et maintenant en 32bits pour faire fonctionner mon appli correctement.

Désolé c'était mon billet d'humeur ;o)

merci encore, je marque comme résolu ... ce sujet pourra peut-être aider quelqu'un ...

[Paul TOTH]

je pense tout simplement que tu utilises une DLL qui ne gère pas les transactions, les nouvelles versions le font (si je ne m'abuse) et du coup tu dois les gérer.

[navyg]

Merci Paul de t'intéresser à mon problème ...

En fait, aucune dll récente ne fonctionne ! celle de 2019 est la plus récente que j'avais trouvé ...

Seule la dll de 2008 fait fonctionner le programme correctement ... Je n'ai pas essayé ma dll de 2003 en fait ...

Et en relisant ton message je le comprends différemment ... tu veux dire que comme ma vieille dll ne gère pas les transactions, elle poste directement, alors qu'avec la dll récente il faut la "forcer" à faire la transaction ? oui mais comment ? j'ai essayé autocommit à true et ça ne fonctionne pas avec la dll 2019, donc je ne sais pas faire ...

J'ai bien envie de ne plus toucher à rien car ça fonctionne comme ça.

Comme quoi c'est dans les vieux pots ... et puis vu mon âge, ça m'arrange ;o)

[SergioMaster]

La dll est dans le même répertoire que l'exe

Ok, mais c'est dit à Firedac ?
Par précaution, je renseignerai la vendorlib dans un composant FDPhysMySQLDriverlink

[navyg]

Bon encore un truc dont je ne soupçonnais même même pas l'existence ... je vais regarder ça ...

[Paul TOTH]

alors je n'ai jamais pratiqué les transactions sous MySQL, depuis des années je bosse sur Firebird...et plus j'avance plus j'utilise mon propre code est structuré différemment que le DataSet

j'ai un enchaînement plus logique
TFBConnection.StartTransaction => TFBTransaction.PrepareSQL => TFBQuery.Execute(Commit: Boolean);

un Query vient forcément d'une transaction, et le commit est explicite.

donc ça ne répond pas à ta question mais les symptômes me semblent clairement liés à un problème de transaction...reste plus qu'à trouver comment forcer le commit

[navyg]

Merci pour ces précisions
Je n'ai même pas eu le temps de regarder car ma chérie m'a trouvé des occupations urgentes
Je vous tiendrai au courant ...

[navyg]

Alors résultat des courses ...
Malgré un composant FDPhysMySQLDriverlink qui indique bien à Firedac la dll utilisée, en 32 bits, la seule dll que j'arrivait à faire fonctionner est celle du 21/05/2008.

La dll 32 bits fournie par mariadb, libmariadb.dll du 3/11/2021 ne fonctionne pas du tout avec un message d'erreur à la tentative de connexion, ce qui est un comble.

La libmysql.dll du 18/03/2019 démarre à la connexion, mais ne fonctionne pas bien lors d'un post.

Ensuite, j'ai exploré les composants firedac et j'ai trouvé un TFDTransaction que j'ai essayé toujours avec cette dll de 2019, avec tout les commit en automatique, mais ça ne fonctionnait pas.
Puis j'ai introduit après le post, un FDTransaction.Commit, mais ça me faisait une erreur comme quoi la transaction n'était pas démarrée.
J'ai donc ajouté avant un FDTransaction.StartTransaction, et là miracle ! ça fonctionne !
J'ai donc ensuite supprimé le Commit, et ça fonctionne encore, mais que sur le 1er post, les suivants n'étant pas pris en compte.
Conclusion, les mots magiques, enfin les instructions magiques avec la dll de 2019, sont StartTransation suivis de Commit après le post.
C'est un peu comme le sketch de Coluche sur le nouvel Omo qui lave la tache dans le noeud du torchon: "le nouvel Omo c'est comme l'ancien Omo, mais c'est plus long, il faut faire les noeuds"
Et bien la dll la plus récente (de 2019), c'est comme la dll de 2008, mais c'est plus long, il faut ajouter un composant TFDtransaction et les instructions StartTransaction et Commit après chaque post ....

Alors je teste ça avec la dll de 2008 ... et bien dès que je mets un composant TFDTransaction relié au TFDConnection, il faut également les instructions ci-dessus ! S'il n'y a pas de TFDTransaction, pas besoin des instructions magiques (?).

Merci Paul de m'avoir mis sur la voie, je pense en effet que la dll la plus récente qui doit gérer les transactions doit être "forcée" alors que la dll de 2008 poste directement sans autre forme de procès car elle n'intègre pas les notions de transactions.

Alors maintenant se pose la question : est ce que je laisse le programme comme ça avec ma vieille dll qui fonctionne bien (pour l'instant), ou bien est ce que je modifie tout le programme en rajoutant un StartTransaction et un Commit après chaque post (dans un afterpost par exemple ... pour toutes les tables !!!!)

Quel est votre avis ?

[navyg]

En ce qui concerne TFDPhysMySQLDriverLink, j'ai l'impression que ça ne sert pas à grand chose.
Lorsque je désigne une dll en particulier par la propriétés VendorLib, il semblerait que le programme ne trouve pas la dll.
En revanche, même en désignant une autre dll dans VendorLib et que je mets la bonne dll dans le même répertoire que l'exe, ça fonctionne très bien ...
Ou alors je n'ai pas compris comment ça marchait ...

[navyg]

Bon, j'ai fait le choix : j'ai mis à jour le programme avec les transactions.
Hormis le boulot que ça m'a donné, ça n'enlève rien, ça marche toujours aussi bien en 64 bits, et je peux utiliser une dll plus récente. Et si un jour les évolutions amènent à en passer par les transactions "forcées", je serai prêt.

Par contre je n'ai toujours pas compris pourquoi je ne peux pas faire tourner la version 64 sur un des postes ... Je trouverai !

[free07]

Bonjour,

Par contre je n'ai toujours pas compris pourquoi je ne peux pas faire tourner la version 64 sur un des postes ... Je trouverai !

Quel est le message d'erreur rencontré sur ce poste ? Il se peut que la dll mysql (ou mariadb) ait besoin de dépendances qui ne sont pas installés sur ce poste ( des dll windows ).

[navyg]

Bonjour,

Le message est le suivant :
[FireDAC][Phys][MysSQL]-1101. Version MySQL non supportée [302050000]. Les versions postérieures à la version 3.20 du serveur et du client sont supportées.

Les DLL sont identiques sur tous les postes et les versions de windows 10 également.

J'ai même essayé d'installer le connector 64 bits mariadb dernière version sur le poste en question, mais rien n'y fait.

J'ai cherché toutes les versions mariadb.dll ou libmysql.dll sur le poste, mais je n'ai rien trouvé de particulier à part celles que j'ai installées. ???

Bon maintenant la version 32bits tourne bien, mais c'est bizarre quand même ...