LiveBinding entre un Query et une Grid

Bonjour,

je commence par la mauvaise attitude (la régression) : En FMX, y a-t-il un moyen de créer une chaîne Connecteur-DataSet-DataSource -?- Grid ? Ce serait pour moi une solution de facilité... enfin une solution de secours au cas où je n'arriverais pas à me dépêtrer de ce problème dans un temps raisonnable.

Sinon mon problème est le suivant : J'ai lié mon UniQuery1 (UniDac) à ma Grid1. Je lis une table de mon serveur distant mariaDB (Androïd compris) : génial exactement le même code. Des styles différents histoire de pratiquer un peu.

Je complique un peu la chose. J'introduis un SQLUpdate. RAS. (Y compris sur l'OS X :oops:) avec très peu de code finalement.

Je complique encore : sur mes applications Desktop, pour fluidifier et sécuriser, j'utilise une base locale SQLite:memory:

Dans un premier temps la base locale SQLite se charge à partir de la base distante MariaDB.
Puis j'utilise la configuration précédente : une connexion SQLite et la Grid est reliée à ce connecteur. Mais parallèlement qu'en je fais un Update sur cette table, j'aimerais qu'elle fasse avant un Update (ou qu'elle essaie) sur la base distante mariaDB. J'aimerais que les 2 transactionnels soient imbriqués comme je pratique en Windev.

Et là, je patauge ! Quel événement du BindSourceDB1 faut-il intercepter et comment neutralise-t-on le Update sur la table SQLite si on obtient un échec (donc conclu par un rollback) sur la table mariaDB vu que l'Update sur la table SQLite est "automatique" (intégré ? enfin quasiment sans lignes de code) ...

Ce n'est peut-être pas très clair ...... Evidemment j'ai un autre connecteur et un autre UniQuery liés à mon serveur MariaDB.
Merci pour vos lumières.

Bonjour Gilles,

je pense qu'en englobant les transactions il ne devrait pas y avoir de soucis majeur
en gros (ce n'est pas du code, juste de la démarche) :

Citation:

---

LocalDb.StartTransaction;
LocalDB.Update;
MariaDB.StartTransaction;
try
MariaDB.Update;
MariaDB.Commit;
LocalDB.Commit;
except
LocalDB.Rollback;
MariadB.Rolback;
end;

---

pas de livebinding ;)

Bonjour Serge,

Question mal posée... Je le sentais. Pour le code que tu fournis : C'est bon. Je procéderai(s) quasiment ainsi.

Pas de LiveBinding ? Oui si c'est un événement étranger à la Grid (genre utilisation d'une Form tierce pour updater ou insérer). Mais si c'est un événement lié à la Grid... tu te rappelles du changement d'index des lignes en Drag and Drop ? Ou un double clic sur une ligne qui change la valeur d'un champ (par exemple actif/non actif ou n'importe quoi d'autre). Dans ce cas là, tu codes (tu fais appel au) le Dataset directement dans l'événement de la Grid, donc comme on le ferait dans une chaîne classique DataSet-DataSource-dbGrid ?

Je me suis peut-être laissé impressionner par la partie inférieure de l'image suivante qui commence bien par LiveBindings... Le tout étant de déclencher l'événement évidemment. d'où la première partie de la question : "Comment intercepte-t-on ..."
Pièce jointe 179413

Bonjour,

Citation:

---

Envoyé par Selzig

Je me suis peut-être laissé impressionner par la partie inférieure de l'image suivante qui commence bien par LiveBindings...

---

oui c'est le cas, mais si tu regardes bien tu verras qu'il s'agit en fait du Dataset et non du LiveBindings sensu-stricto.

Pour les changements d'index, via le Drag/Drop la solution que je t'avais proposé ne faisait intervenir aucune modification de données (merci TMSFMXGrid).
Dans le cas de figure où il faudrait changer une donnée (l'ordre) :koi:
a) je repartirai sur l'idée d'un champ calculé
b) j'utiliserai, bien que je n'en soit pas un fan, recno (et si possible le Row(?doute) de la TMSGrid, un livebinding serait-il possible? pas essayé )
c) j'attendrai une validation de groupe (car de toute façon il faudrait ensuite modifier toutes les lignes sur MARIADB, j'utilise ce terme pour parler de la base sur le serveur) en utilisant le nouvel ordre. Là pas de livebindings je pense , du pur SQL ressemblant à s'y méprendre a un comportement de réplication de données

J'aimerais en faire un essai ce WE, je n'ai jusque là pas encore abordé la copie en mémoire d'une table ce qui me ferait d'une pierre deux coups
mais ma priorité reste quand même l'équivalent d'un DBLookUpCombobox, si pratique et si utile pour mes programmes, je ne connais pas beaucoup de bases de données qui n'ai pas quelques Foreign Key qui trainent avec des tables genre id_Code/Libelle

Je jette ces idées ce matin en guise d'échauffement du cerveau ;) un café en main

Serge

Bonjour Serge,

C'est curieux quand même cette technologie LiveBinding(s). Entre 2 objets, elle me semble unidirectionnelle (ie dans un seul sens), dans le cas présent du DataSet vers la Grid.... Et curieusement, pas de la Grid vers le DataSet. Quel est son avantage alors par rapport à l'ancienne solution ?

D'ailleurs je me posais également la question les styles qui ne sont pas "héritables". Quant à changer radicalement l'approche, autant offrir de nouvelles capacités.

Bonne journée.

Citation:

---

Envoyé par selzig

C'est curieux quand même cette technologie LiveBinding(s). Entre 2 objets, elle me semble unidirectionnelle (ie dans un seul sens), dans le cas présent du DataSet vers la Grid.... Et curieusement, pas de la Grid vers le DataSet.

---

attention, il y a livebinding et livebinding , ceux que tu fais en "rapide" via le designer, généralement non modifiables par la suite et ceux que tu crées toi même
ensuite tu verras qu'il y a aussi une possibilité de modifier le sens (propriété Direction d'un livebinding) de modifier "le format" CustomFormat, CustomParse sans parler des événements OnAssignedValue et OnAssigningValue << Tout ça est très confus et peu documenté

Citation:

---

Quel est son avantage alors par rapport à l'ancienne solution ?

---

un vrai casse tête par rapport au VCL à mon avis

Citation:

---

D'ailleurs je me posais également la question les styles qui ne sont pas "héritables". Quant à changer radicalement l'approche, autant offrir de nouvelles capacités.

---

ne confonds pas style et livebindings , il s'agit de 2 choses différentes.
!! la suite est pure spéculation et contient une part non négligeable de supputations/conneries
le Style (faut-il distinguer les Styles VCL de FMX : je le pense) est la partie "graphique"
!! je continue uniquement sur FMX
avec le style FMX tu modifies un composant existant (redessin,ajout de composants enfants etc...) et donc peut y rajouter des propriétés (voire peut être mêmes des méthodes ?) en fait je dirais que cela t'évite de créer des composants spécifiques.
prenons un exemple simple un Tedit avec un bouton enfant
1° manière : poser un TEdit,un TButton sur une forme, glisser le TButton pour en faire un enfant de TEdit, modifier sa propriété alignement
2° manière : poser un TEdit et indiquer son style lookup (bon là , y a comme un bug non encore corriger en XE8 voir par exemple le ClearEditButton)
2° bis : poser un Tedit , faire un clic droit et ajouter un élément (pour le ClearEditButton, miracle pas besoin de code un clic sur le bouton et la saisie s'efface d'où ma réflexion sur les méthodes)
3° manière : Créer/modifier un style nommer un nouvel élément de Style dans un TLayout mettre un TEdit,un TButton ... sauvegarder le style (AFRO) ... et poser un TEdit et indiquer cette fois ci le StyleName (cette dernière partie est spéculative, cela fait un moment que je n'ai pas repris ça) Mais ce n'est pas fini, il faudra encore lié la méthode Onclick du bouton à une procédure (relire mon tutoriel sur mes premiers pas Style Firemonkey)

bref je ne te fait pas dire que la première manière est de loin la plus simple ;) cependant la 2 bis a ses avantages :) quant à la troisième sur un Tedit peu d'applications (quoique j'entrevois quelque chose : en y matînant un TEffectShadow , un expression régulière en propriété on arriverait à l'équivalent d'un joli TMaskEdit :weird: à y réfléchir)

Passons aux LiveBindings : Peu d'entre nous ont utilisé les RTTI pourtant c'est s'en qui se rapproche le plus (oserai-je dire "c'est la même chose")
là on joue sur les propriétés/membres accessibles des composants (visuel ou non). Mon reproche sur ces derniers : le peu de documentation (mais je l'ai déjà dit). Aucune explication des mécanismes! par exemple, pour reprendre le combobox, on peut très facilement le remplir via une table tout en liant la valeur sélectionnée à une autre table (via le concepteur visuel AMHA c'est une chienlit) mais comment ça se contrôle vraiment (chargement de la liste, positionnement dans la liste etc...) aucune explications. Pour en revenir à mon équivalent DBLookupComboBox (c'est là où je coince) :
- Chargement de la Liste référence (table "détail") ok
- Liaison avec valeur (clé étrangère) de la Table "maitre" ok
tout irait pour le mieux si cela ne fonctionnait pas qu'une seule fois par éxécution du programme ! (même en fermant/réouvrant les tables)
Cela étant, mes lectures m'ont porté vers "les effets de bord" (sideeffects) des livebindings : OUI, il y a un fameux potentiel (et je ne parle même pas des expressions :roll:)
Mais peut-être (de mon point de vue sûrement) au détriment d'une lisibilité du programme (pour lire le programme il faut à la fois voir le code et les liaisons dans le dfm, à mon avis ça craint en maintenance par personnes tierces)

Bonjour,

Citation:

---

Envoyé par SergioMaster

Mais peut-être (de mon point de vue sûrement) au détriment d'une lisibilité du programme (pour lire le programme il faut à la fois voir le code et les liaisons dans le dfm, à mon avis ça craint en maintenance par personnes tierces)

---

Et pas que les personnes tierces... Ma mémoire a un peu de mal quand je reprends un projet quelques mois plus tard. Donc je cherche à rester simple autant que possible.

Une doc intéressante : http://www.tmssoftware.biz/download/...idDevGuide.pdf notamment la partie LiveBindings [Cela concerne les TMSFMXGrid uniquement]. Ces grids font vraiment gagner un temps fou... d'autant que le documentation peut porter ce nom. C'est l'impression qui me chatouille maintenant. J'ai porté le fonctionnement de ma "Grid" Windev en Delphi/TMS/Unidac... et j'avoue que cela fonctionne très bien sans finalement représenter une quantité de travail (et surtout d'errances) excessifs. Donc, j'attaque FastReport. La première question est de savoir si la version intégrée suffit. J'ai besoin d'écrire verticalement, de définir de manière dynamique le nombre de "colonnes", de calculer dynamiquement la taille de certaines simplement à la lecture de la table SQLite, de jouer avec les couleurs des cellules et si possible de créer un document pdf ou plusieurs et de les chaîner. Je connais assez bien LazReport donc je pense que c'est jouable avec FastReport... à condition que le version Firemonkey livrée avec Delphi ne soit pas trop limitée.

Pour les autres composants : http://www.tmssoftware.com/site/manuals.asp#Firemonkey