Version imprimable
Bonjour,
Dans ce post, SergioMaster donne cet exemple pour utiliser un TZSQLUpdate
J'aimerais savoir à quoi correspond les «:CODE_POSTAL» par exemple !Code:
2
3
4
5
6
7
8
9
10
11
Comment faire le lien avec ma dbGrid ou mon dbChamp ?
:CODE_POSTAL
':' dans une requête précise qu'il s'agit d'un paramètre
pour alimenter les paramètres il faut utiliser quelque chose comme ceci
A+Code:dataset.parambyname('code_postal').asString:='56000';
Merci de ta réponse, maintenant, ma question est comment faire pour auto alimenter les requêtes par un dbgrid ?
la dbgrid est directement attachée à un dataset
le passage en mode Edit/Insert et le Post sont donc automatique
pourquoi utiliser un SqlUpdate dans ce cas?
Je ne comprend pas ce que tu veux faire.
Peut être fonctionnes-tu en transactionnel (Start transaction)
Si tu veux piloter intégralement tes insert et update utilise plutot StringGrid
à chaque validation tu alimentes tes paramètres et tu exécutes ta requête
Je ne suis pas sûr que tu vois plus clair maintenant :calim2:
A+
:mouarf: Non, je n'y vois pas plus clair ...
En fait, je me base sur l'exemple du post fourni en lien sur le sujet initial.
Et, d'après ce que j'ai cru comprendre, la personne plaçait un TZUpdateSQL, TDataSource et un dbGrid.
En renseignant comme indiqué les chaines SQL, aucun code ne semblait utile.
Donc, mais je ne comprends pas comment on envoie les valeurs dans la requête. Comment le TZUpDateSQL fait le lien entre les données de la colonne et les variables de la requête !
je suis en déplacement pour l'instant , si cela peut attendre , je referais un tour sur le forum vendredi pour donner tout les détails nécessaires
Bonjour,
Désolé je n'avais pas lu le post... et je vous conseillais avant de le lire de consulter justement une discussion que j'avais eu avec SergioMaster.
Je n'ai jamais réussi à faire fonctionner un ZupDateSQL sans dbNavigator... Mais on peut très bien s'en passer* (du dbNavigator et du zUpdateSQL) en ajoutant un ZQuery pour mettre à jour la base, l'autre étant réservé à l'affichage de la dbGrid.
Avec le dbNavigator, cela a "passé" si l'on peut dire. J'étais sous mySQL avec des bases distantes hébergées. Quand je dis cela a passé, c'est si j'excepte un plantage aléatoire résiduel non reproductible lors du refresh, plantage qui a toujours été problématique car "bloquant la dbGrid (?!)"... donc inexploitable en production. L'autre solution (avec les 2 zQuery) fonctionne toujours en production [0.9.26.2-Zeos 6.6.4 - XP et Linux]. J'espère que la dernière version de Zeos a rectifié le tir. Mais comme vous le savez, malgré ce petit problème et un peu d'UTF8 dans les Memo, je continue à faire de la pub pour cette bibli...
Cordialement. Gilles
* et à mon avis faire bien mieux
Bonjour,
Et merci à vous tous pour vos réponses.
En fait, je me suis lancé. En créant les lignes SQL et en mettant dans les variables les noms des champs de la table. Et, là ! Ô Miracle ! La base de données (sous SQLite3, je ne l'avait peut-être pas précisé) se met à jour toute seule. Seul bémol, si on ouvre la gestion SQL par clic droit sur le composant, les coupures de lignes ne sont pas interprétées correctement lors de l'execution SQL. Il faut les refaire dans l'inspecteur d'objets, mais ce n'est qu'un détail.
Comment ça fonctionne, je n'ai que des suppositions, pas d'explications, donc j'attends avec impatience le cours de Maître Sergio ! :ccool:
Houlà , pas de cours :mrgreen: , j'ai laissé tombé cette casquette depuis longtemps :PCitation:
Envoyé par Louis Griffont
si mes souvenirs sont bons ( l'âge ...) concernant le post cité , ce n'était qu'un petit programme pour illustrer l'utilisation d'un ZUpdateSQL sur une table Firebird , celui-ci ayant été fait "à la paresseux".
donc : Attention ce qui va suivre dépend de la BBD , ici je parle de Firebird
Comment fonctionne le ZUpdateSQL ? en fait (pour simplifier) il s'agit d'un stockage de requêtes paramétrées (le fameux ':' devant le nom de colonne quand il s'agit de firebird ) . Les paramètres étant généralement (mais on peut jouer avec) les noms de colonnes de la ztable ou zquery et donc fourni par ces derniers . (enregistrement en cours)
un nouvel avertissement : dépendant de la version des ZEOS l'outil créateur de requête n'est pas toujours au point (c'est le Dièse a ton Bémol :D) il faut souvent revenir sur le SQL généré (les clauses WHERE sont généralement à revoir, quelques fois les paramètres ne sont pas ou mal signalés etc..)
Dans le cas simple que je donnais en démonstration , j'utilisais une table 'USAGER' contenant deux colonnes CODE_POSTAL et VILLE (pourquoi ai-je appelé ma table USAGER .... mystère en fait j'ai du faire un test sur une table existante de mon appli et vouloir simplifier à l'extrême) .
Comme c'était un programme 'à la paresseux' j'avais effectivement utilisé un dbnavigator pour valider mes modifications et permettre l'insertion
cependant ceci n'est pas obligatoire ! c'était juste une facilité (cf. mode du programme) me permettant de ne pas faire de gestion d'évènement sur la grille et/ou le dataset pour ce qui concerne la validation .
tout à fait , cependant , je te ferais remarquer qu'en fait ton ZQuery n'est ni plus ni moins que une des SQL du composant ZUpdateCitation:
Envoyé par selzig
Donc , encore une Remarque surtout bien penser que les SQL générés par l'outil de TZUpdateSQL ne sont pas gravés dans le marbre et que ceux-ci sont modifiables dans le programme !!
mon poil dans la main parle encore : cela permet simplement de ne pas avoir a programmer tous ces "query.parambyname.value:=..."
autre remarque , méfiez vous comme de la peste du refreshSQL généré
Voilà , j'en reste là . des remarques des questions ? à ta disposition
Serge dit "Maitre" :mouarf::mouarf::mouarf::mouarf:
Merci Ô Maître ! :hola:
Ne t'inquiètes pas, je n'en suis qu'au début, alors... «I'll be back !» 8-)
Ma base est en SQLite (le programme est pour moi, et pour moi seul !)