LiveBinding et verrou

Bonjour,

je cherche des exemples de code pour essayer de comprendre comment on bloque un enregistrement que l'on veut modifier dans une table mariaDB. Ce n'est pas la requête de verrouillage qui m'interroge mais plutôt où elle est placée dans le code sachant que j'utilise le transactionnel.

3 configurations m'intéressent :

• soit on modifie directement dans une Grid "livebindée" avec son SQLQuery
• soit on modifie dans la Form contenant la Grid mais dans d'autres champs que ceux de la Grid elle-même "livebindée" avec un ou 2 SQLQueries (et là déjà je vois beaucoup moins bien)
• soit on utilise 2 forms, une contenant la grille et l'autre contenant les champs à modifier (2 SQLQueries dans un "datamodule" ?)

En Lazarus l'approche ne me pose pas de problème ni en C++, mais avec la nouvelle approche de Delphi, comme je perçois imparfaitement le mécanisme de fonctionnement qui pour moi ressemble pour l'instant à des recettes de cuisine, si quelqu'un(e) pouvait m'indiquer les pistes, cela m'éviterait d'errer sur le Web. J'ai lu les tutos de Serge mais je ne pige pas. Il faut que j'arrive à comprendre cette :furieux::scarymov::zekill: de livebinding et cette non moins :furieux::scarymov::zekill: de styles sinon, visiblement, je passe à côté de 2 pans complets de FMX.

Merci d'avance. Gilles

Bonjour Gilles,

je n'ai aucun tutoriel là dessus et encore une fois je doute que ce soit Livebindings le nœud du problème Firedac à la rigueur mais pas Livebindings qui ne fait que des liens entre les données et les éléments de l'interface utilisateur (en réduisant un peu)

En simplifiant : livebindings = liaison entre données et interface
Styles = apparence de l'interface
Firedac (ou AnyDac) ou tout composant d'accès aux données = liaison avec la BDD
Bien sûr il y a quelques ponts mais à ma connaissance pas avec le verrouillage

Prenons le cas une Grille liée par Livebindings, que se passe t-il ? (pour ce que j'en ai compris pour l'instant)
Tu ouvres la requête, livebindings dans son coin lit tout ou partie (Select) de la table et l'affiche. Dans son coin c'est le truc important, en fait il doit y avoir une sorte de clonage de la requête, ta requête principale reste sur le premier enregistrement.
Un "synchronisateur" (la petite * du concepteur de liaisons visuelles) autre mécanisme (quand on se fait la liaison "à la main" il faut le renseigner) se charge du déplacement dans la grille conjointement avec l'ensemble de données.
Tout autres éléments simples (edit, label etc..) liés le sont sur l'enregistrement en cours.

Quelques "ponts" avec les liens :
- unlien.active:=false empêche un rafraichissement du composant liè unlien.active:=true, devine :lol:
Au niveau d'une listview ou d'une grille (donc lié non pas à un mais un ensemble) c'est comme si tu faisais monensemble.active:=False; monEnsemble.active:=true, à comsommer donc lorsque l'on sait ce que l'on fait ;)

- De même lien sur des listes LinkList ou LinkGrille contient aussi des évènements je ne les aient pas encore tous compris mais le OnAssignedValue serait un équivalent de AfterScroll , OnActivated de AftrerOpen, OnActivating de BeforeOpen où je doute c'est sur le OnAssigningValue peut être un OnChange ou OnAfterChange :koi: en tout cas je ne maitrise pas ce dernier.

Anyway dirait ma belle sœur, les trois cas que tu exposes pour moi n'impliquent qu'une seule requête c'est en général avec l'UpdateSQL (propriété UpdateObject) associé que je joue et c'est dans celui-ci (du moins avec Firedac) que le verrou pourrait intervenir. J'utilise très peu les verrous et donc ne peut te sortir comme ça (fin de journée, rdv chez l'acuponcteur, puis 2 jours de déplacement) un truc complet juste une image
Pièce jointe 432141
Tu remarqueras un LockSQL qui devrait te mettre sur la voie sans que Lao Tzeu n'ai besoin de te couper la tête

Bonjour Gilles,
Durant mon parcours (Nantes-Limoges) j'ai repensé à ce que j'ai écrit

Citation:

---

les trois cas que tu exposes pour moi n'impliquent qu'une seule requête

---

je devais être plus fatigué que je pensais (début de journée 5h00) je procède presque toujours avec 2 SQL un pour remplir la grille (en général lecture seule) et un qui accède à un seul et unique enregistrement (celui qui peut donc être verrouillé et modifié) toujours en utilisant le UpdatSQL (en particulier en cas de besoin de jointures)

Bonjour,

comme d'habitude Serge, tu as raison. Donc d'abord, j'essaie de découvrir FireDac et de le régler proprement :

Pièce jointe 432330

Alors déjà, mes paramétrages de FireDac sont "incertains" alors qu'ils sont maitrisés pour UniDac.

Questions concernant FireDac

1. Le FDTransaction est-il lié à FDConnexion ou à (FDQuery et FDUPDate) : on peut le lier aux 3.
2. Faut-il utiliser 2 FDTransactions dans la mesure ou le FDQuery fonctionne en autocommit(1) alors que le FDUPDate fonctionne en autocommit(0) ?
3. Lors d'une modification comment est géré le LockSQL :
   
   • dès que je rentre dans un champ de la table,
   • ou au moment où je valide la modification ?
   Si c'est ce dernier cas (très probablement) cela ne me convient pas : on ne laisse pas un utilisateur modifier les champs pour lui annoncer au moment où il valide les modifications que l'enregistrement est bloqué :weird:

Je pratique ainsi et je ne veux surtout pas changer mon IHM : Si on veut faire la modification directement dans la Grid par exemple, dès qu'on rentre dans un champ ou que l'on clique sur le nbEdit du DBNavigateur, le programme lance la procédure (ie la requête) de verrou sur l'enregistrement concerné. S'il ne le peut pas, il en avertit l'utilisateur. S'il le peut, l'utilisateur effectue ses modifications et la validation débloque l'enregistrement. J'associe un Timer dès le verrouillage effectué, qui au bout d'un certain temps envoie un rollback, des fois que l'utilisateur se serait endormi sur son clavier...

En tout état de cause, le LiveBinding interagit avec la chaine de connexion... et c'est là que cela se passe mal. Alors en Lazarus, en C++, je trouve cela facile à gérer. Et si tel était le cas avec le LiveBinding, ce fil n'existerait pas.

Je vais mettre mes codes concernant cette discussion avec mes libmysql.dll win32 et win64 (puisqu'il est nécessaire de les distribuer contrairement à UniDac). Ne pas oublier de placer la libmysql.dll win 32 dans le bin de Delphi :
Pièce jointe 432360

J'ai créé un utilisateur sur une base de test hébergée* (basefmx) qui contient 2 tables (masterfmx et slavefmx) liées par une clé étrangère.

Cordialement. Gilles

---

* donc accessible à distance : Le FDConnection est paramétré dans le code.

Bonjour,

Citation:

---

1- Le FDTransaction est-il lié à FDConnexion ou à (FDQuery et FDUPDate) : on peut le lier aux 3.

---

c'est le principe des degrés FDConnexion c'est la transaction par défaut si la requête n'a pas une transaction particulière FDQuery donc dans le schema la connection est lié à une transaction T1 et la requête à un transaction T2 c'est T2 qui est pris, si la requête n'est pas liée à une transaction c'est T1
Tu remarqueras également que la connection propose de remplir une UpdateTransaction donc c'est encore plus modulable


FDConnection (sans rien) une transaction de base existe quand même (à l'instant de mémoire je suis incapable d'en donner les termes exacts)
FDConnection+Transaction voir au dessus (UpdateTransaction à les mêmes propriétés)
FDConnection+Transaction+UpdateTransaction (comme son nom l'indique elle s'applique à tout opération de mise à jour)

Si tu veux un comportement particulier pour une FDQuery ou FDTable alors tu rajoutes les transactions nécessaires sinon c'est celles de la connexion qui s'appliquent

Citation:

---

2 - Faut-il utiliser 2 FDTransactions dans la mesure ou le FDQuery fonctionne en autocommit(1) alors que le FDUPDate fonctionne en autocommit(0) ?

---

je pense que ma réponse au point 1 répond au 2

Citation:

---

3- Lors d'une modification comment est géré le LockSQL: dès que je rentre dans un champ de la table ou au moment où je valide la modification ?

---

j'avoue, dans le cas d'une grille ne pas trop savoir sinon oui, l'erreur est levée à la demande de modification
il faudrait que je lise cette partie dans le bouquin de Cary Jensen pour écrire une certitude mais je l'ai pas sous le coude ;)

en PS vire ces FDGuix..., FDPhys ... qui sont en fait juste là pour faire inclure des unités (du moins pour le premier) quand au second, sauf emplacement spécial de library il est également inutile
et enfin si tu mets toutes la partie FDxxxxx dans un datamodule c'est encore mieux ;)

Bonjour,

alors j'ai avancé un peu, le but étant de cibler Windows, OS X et Ubuntu.

Comme je l'imaginais, j'ai été incapable d'utiliser FireDac sous OS X et Ubuntu. Le problème c'est visiblement la libmysql nécessaire.... Et d'un autre côté, je compile statiquement l'environnement Qt en y intégrant les bibliothèques (notamment mariaDB) ce qui fait que comme avec UniDac, je n'ai pas besoin d'installer les bibliothèques d'accès aux BDD sur les postes clients dans aucun des 3 OS. Donc pas d'aide de ce côté et ce n'est donc pas non plus Qt qui imposerait sa loi puisqu'il est totalement autonome.

Alors je suis revenu à mes habitudes.
J'ai testé en remplaçant Firedac par Unidac. Et comme sous OS X, avec Ubuntu, cela se fait sans problème. Génial 8-)

Pièce jointe 432819

Pendant que j'y étais, j'ai testé TMS avec FMXlinux. Cela fonctionne 8-). Mais la "compatibilité" n'est pas aussi immédiate que celle d'UniDAC, sans être compliquée.
Dans le projet, il faut ajouter les répertoires où sont installés les composants TMS.
Donc Projet->Option->Compilateur Delphi-> Chemin de recherche :

Pièce jointe 432820

J'ai fait un essai avec FastReport sans préciser les répertoires de recherche, et cela ne fonctionne pas. Je les préciserai lundi et referai un test.

@Serge : Sous Unidac pour le SQLupdate, tu peux préciser un SQLQuery spécifique (UniQuery2) et évidemment cela simplifie beaucoup la chose parce que tu peux piloter indifféremment chaque SQLQuery alors qu'avec FireDac et un seul SQLQuery pour l'ensemble (peut-être qu'on peut faire avec 2, je n'ai pas "trouvé"), la mécanique est plus intégrée et donc, pour moi, beaucoup plus difficile à comprendre.

Bon WE. Cordialement. Gilles

Bonjour Gilles

Citation:

---

Envoyé par Selzig

Le problème c'est visiblement la libmysql nécessaire....

---

AMHA c'est juste un problème de déploiement mais bon, c'est une autre histoire.
Je tente justement d'utiliser Firebird 3 sur Android (puisque à priori Firebird est déployable sous cet OS) et c'est bien le déploiement mon soucis
Qu'Unidac intègre directement les dll est évidemment un plus (au détriment de la taille du programme je présume ?)

Citation:

---

Pendant que j'y étais, j'ai testé TMS avec FMXlinux. Cela fonctionne . Mais la "compatibilité" n'est pas aussi immédiate que celle d'UniDAC, sans être compliquée.
Dans le projet, il faut ajouter les répertoires où sont installés les composants TMS.

---

cela me semble logique puisque les paquets ne sont pas compilés pour cet OS il faut indiquer les répertoire sources
Pour FastReport cela me parait donc un peu compromis mais qui sait ...

En post scriptum, une session CodeRage de Ray Konopka sur les styles m'a fait comprendre ce problème de style (default/windows 10) que tu avais posé durant l'été

Bonjour Gilles,

Citation:

---

Le problème c'est visiblement la libmysql nécessaire....

---

je rebondis là dessus, en répondant à un autre post j'ai pensé à regarder cette page http://docwiki.embarcadero.com/RADSt...rver_(FireDAC) qui devrait répondre à ce souci

Bonjour Serge,

Excellent !:yaisse2:
Je me demande toujours comment tu trouves "cela" 8O

Bonne fin de WE. Cordialement. Gilles

Bonjour Gilles,

Citation:

---

Envoyé par Selzig

Je me demande toujours comment tu trouves "cela"

---

Par hasard un fil de lecture (ou visionnage) conduisant à un autre qui conduit à un autre etc... allié à un soupçon de mémoire quand un os me résiste

Bonne journée

Bonjour,

le problème est réglé. Je n'ai utilisé le LiveBinding que pour la lecture de la Grid. Pour le reste j'ai pris la méthode que j'utilise de manière "ordinaire".

Merci pour vos aides. Cordialement. Gilles