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