Discussion :

[Invité]

Bonjour,

A tout hasard...

J'utilise ZeosDBO pour me connecter à mes bases. J'envisage d'utiliser un TZupdateSQL associé à un zQuery.
Actuellement, la dbGrid est alimentée par un zQuery et les modifications sont exécutées par un autre zQuery (donc indépendant de la dbGrid) obligeant à une programmation un peu lourde pour les replacements dans la dbGrid après ajout, modification ou suppression d'un champ. Mais l'ensemble fonctionne très bien.

Il semblerait que l'on puisse faire la même chose avec un ZupdateSQL associée au zQuery qui alimente la dbGrid. Mes diverses tentatives sont restées vaines malgré l'article recommandé par SergioMaster dans une autre discussion (http://zeos.firmos.at/kb.php?mode=article&k=12). Au mieux, j'obtiens en effet l'ajout, le zQuery se ferme et son refresh ne fonctionne plus (Err. : DataSet inactif).

L'association d'un ZupdateSQL à un zQuery qui alimente une dbGrid est-elle une solution plus performante que la mise en oeuvre de 2 zQuery indépendants? Quel(s) gain(s) peut-on en attendre ?

Cordialement. Gilles

[SergioMaster]

Salut,

Pour te répondre sur l'utilité , voilà ce que j'ai fait :

Création d'un petit programme pour gérer un petit fichier de contrôle de saisie , disons par exemple un fichier CodePostal,Ville . Va savoir pourquoi j'ai appelle cette table USAGER enfin peu importe

environnement Firebird 2.1 , Lazarus 9.27, Zeos 6.6.4 (certainement pas la dernière version car j'ai quelques plantons voir la suite)

sur la form , j'ai posé : un DBGrid,un DbNavigator,un TZConnection,un TZTable (mais cela aurait pu être un TZQuery) , un Datasource et un TZSQLUpdate

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
 
unit Unit1; 
 
{$mode objfpc}{$H+}
 
interface
 
uses
  Classes, SysUtils, FileUtil, LResources, Forms, Controls, Graphics, Dialogs,
  DBGrids, DbCtrls, ZConnection, ZDataset, ZSqlUpdate, db;
 
type
 
  { TForm1 }
 
  TForm1 = class(TForm)
    Datasource1: TDatasource;
    DBGrid1: TDBGrid;
    DBNavigator1: TDBNavigator;
    ZConnection1: TZConnection;
    ZTable1: TZTable;
    ZUpdateSQL1: TZUpdateSQL;
  private
    { private declarations }
  public
    { public declarations }
  end; 
 
var
  Form1: TForm1; 
 
implementation
 
{ TForm1 }
 
initialization
  {$I unit1.lrs}
 
end.

Pour le TZSQLUpdate (voilà le bug : un clic droit pour appeler le SQL generator plante dommage il marche bien sous Delphi)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
//DeleteSQL
DELETE FROM USAGER
WHERE  CODE_POSTAL=:OLD_CODE_POSTAL 
//ModifySQL
UPDATE USAGER SET 
CODE_POSTAL=:CODE_POSTAL,
VILLE=:VILLE
WHERE CODE_POSTAL=:OLD_CODE_POSTAL
//InsertSQL
INSERT INTO USAGER (CODE_POSTAL,VILLE)
VALUES (:CODE_POSTAL,:VILLE)

et voilà , pas une ligne de code dans l'unité et pourtant tout fonctionne
(bon , pas tout à fait pour le composant, je pense que le problème est corrigé , il va falloir que je mette la version supérieure )
à noter qu'il y a encore quelques petits bugs avec ce SQLGenerator même sous Delphi

Supposons maintenant que je gère les codes postaux de plusieurs pays et que je ne veuille que ceux de la FRANCE

je remplace le ZTable par un ZQuery
SELECT CODE_POSTAL,VILLE FROM USAGER WHERE PAYS='FRANCE'

je modifie un peu mon code du ZUpdateSQL

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
//InsertSQL
INSERT INTO USAGER (CODE_POSTAL,VILLE,PAYS)
VALUES (:CODE_POSTAL,:VILLE,'FRANCE')

et voilà (toujours pas une ligne)

[chris37]

Salut Sergio et merci pour cette réponse

Tu nous met un petit tutos sur le wiki stp ?

Cordialement,
chris

[SergioMaster]

pour en revenir au petit bug , j'ai fait un gros effort , je suis passé à la version 6.6.5 le SQLGenerator fonctionne , attention toutefois au code généré (je trouve la clause WHERE du Delete et de l'Update un peu tordue )

@Chris37 je suis plutôt fainéant (pour vivre longtemps) et surtout pas très littéraire mais je ferais un effort , si quelque chose dans le style de ma réponse suffit à votre bonheur

[Invité]

Bonjour,

Merci pour la réponse rapide.

J'ai reproduit votre code (avec un zQuery - je n'utilise pas de zTable). Il fonctionne.

Mais je n'utilise pas de dbNavigator : j'ai besoin d'un bouton de duplication. Et d'autre part, je ne travaille pas "dans" la dbGrid (dgRowSelect:=true) : Lors de la sélection d'un enregistrement dans la dbGrid, une fonction charge les valeurs de la ligne sélectionnée dans des tEdit ou plus rarement dans des dbEdit ...

Dans ma configuration, un premier problème rencontré est : à partir d'un simple tButton de validation des champs de saisie, comment déclare-t-on au zQuery qui alimente la dbGrid qu'il faut utiliser la requête d'insertion ou celle de modification du zUpdateSQL ? J'ai essayé avec des zUpdateSQL1.SQL[ukInsert], pensant que l'utilisation "frontale" de zQuery1.SQL.Add('INSERT...') ne peut pas être utilisée : la dbGrid lui est liée. L'utilisation de ce genre de commande (zQuery.SQL.Add...) la vide de son contenu. De ce côté, je n'ai pas trouvé de solution et je doute qu'il en existe.

Par contre, j'ai réussi péniblement à insérer des données dans la table de données en manipulant le zUpdateSQL1 et ceci sans "déconnecter" la dbGrid mais également malheureusement sans pouvoir réaliser des refresh de celle-ci : impossible de faire apparaître le nouvel enregistrement dans la dbGrid (et donc de replacer la barre de sélection sur le nouvel enregistrement)...

Bref, la méthodologie à appliquer dans la configuration qui m'est imposée m'est complètement étrangère (ie dès qu'on se passe du dbNavigator qui "commande" les bonnes fonctions et dès qu'on n'utilise pas la dbGrid pour modifier la table de données).

C'est peu important, l'autre solution avec 2 zQuery indépendants fonctionne bien. Je voulais simplement me rendre compte si l'utilisation du zUpdateSQL était succeptible de présenter un avantage sérieux dans mes développements.

Merci pour l'aide apportée. Bon WE. Cordialement. Gilles

[SergioMaster]

J'avais fait au plus simple étant très fainéant

un problème rencontré est déjà à partir d'un simple tButton de validation

pour ceci rien de plus simple au Click du bouton Valider

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ZQuery.Post;

pour une duplication je verrais quelque chose du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
ZQuery.Edit;
// copie , peut être avec les OLD_Values
 
ZQuery.Post;
// suivi d'un refresh
// avec sauvegarde d'un bookmark pour un retour a la ligne insérée
ZQuery.Refresh;

voire des dbEdit (plus rare)...

Dommage c'est tellement plus simple

impossible de faire apparaître le nouvel enregistrement dans la dbGrid et (et de replacer la barre de sélection dessus).

sisi il faut utiliser GetBookmark et GotoBookMark .
Une petite méthode dans le genre de la première réponse si tu es intéressé ?


Ce qui me donne des perspectives intéressantes pour un Tuto , n'est ce pas Chris37 , un clin d'oeil aussi à JP.NUAGE

[Invité]

Merci pour les explications, mais, désolé, je peine à comprendre :

Qu'est ce qui indique à zQuery.Post l'opération qu'il doit effectuer ? Le zQuery est en SELECT initialement : il remplit la dbGrid. Le tButton et les tEdit n'indiquent rien au zQuery... et à mon avis, il n'est pas possible de changer directement la requête du zQuery en UPDATE ou INSERT sans modifier l'affichage de la dbGrid...

Alors dans ces conditions, je suppose que c'est le fait du zUpdateSQL. Mais pourquoi choisirait-il plutôt l'option de la requête d'insertion, que celle de modification voire de refresh ? le dbNavigator l'indique, lui, lorsque vous choisissez l'opération que vous voulez engager... et peut-être éventuellement la dbGrid si vous modifiez directement une de ses lignes ou si vous remplissez la ligne vide en bas pour l'insertion...

Dans mon cas, il faut que cela reste simple : la base est multi-utilisateurs et de plus la dbGrid est rafraîchie très régulièrement (lorsque le programme détecte une modification de la table parcourue). D'où l'utilisation du zQuery "spécialisé" (zQueryBDD) pour la dbGrid et d'un "à-tout-faire" (zQuerySUID) pour le reste...

Pour la simplicité des dbEdit (notamment en cas de champs calculés) et l'utilisation des dbMemo, je ne me suis pas rendu vraiment compte de leur simplicité. J'ai dû passer à côté d'une évidence mais pas de certaines difficultés ANSI/UTF8 (le code doit fonctionner sous windows et linux) et de bugs pour le dbMemo...

Cordialement. Gilles

[SergioMaster]

Qu'est ce qui indique à zQuery.Post l'opération qu'il doit effectuer ? Le zQuery est en SELECT initialement : il remplit la dbGrid. Le tButton et les tEdit n'indiquent rien au zQuery... et à mon avis, il n'est pas possible de changer "simplement" la requête du zQuery en UPDATE ou INSERT sans modifier l'affichage de la dbGrid...

En fait c'est l'etat de la query (Query.State) et le DataSource lié qui indique au ZupdateSQL quelle requete prendre (je simplifie)

petit oubli . Je n'ai pas indiqué que la propriété UpdateObject devait être renseignée avec le nom du ZupdateSQL

de certaines difficultés ANSI/UTF8 sauf a mettre ma base en UTF8

La aussi , je l'avoue, je bute

et de bugs pour le dbMemo...

Jamais trouvé , sauf bien sur UTF8

[Invité]

Bonjour,

SergioMaster, merci pour votre réponse.

En ce qui concerne des bugs dbMemo, par exemple http://bugs.freepascal.org/view.php?id=12997&nbn=1 qui persistait sur la version stable 0.9.26. Je n'ai pas essayé sur la 0.9.26.2. Il y a eu également des problèmes de scroll. Evidemment avec une version SVN, le problème cité semble corrigé mais, qu'est-ce qui fonctionne aujourd'hui avec la 0.9.26.2 et qui ne va pas fonctionner dans la dernière 0.9.27 ? J'ai décidé, une bonne fois pour toute, de n'utiliser que des versions stables (un vieux réflexe de "Debianiste") : au moins les bugs sont répertoriés.

Pour le reste, je crois qu'on dit la même chose. Compte tenu de l'utilisation de mon zQuery qui reste en lecture simple de la table, son état est toujours le même [en lecture] et je ne le change jamais... A la rigueur un zReadOnlyQuery ferait l'affaire dans ma programmation. J'avais retenu le zQuery justement parce qu'on pouvait l'associer à un zUpdateSQL sachant que ma première expérience n'avait pas été concluante et que j'avais reporté le problème à plus tard (puisque 2 zQuery faisaient l'affaire).

C'est pourquoi je demandais s'il y avait moyen, sans quitter le mode lecture du zQuery, de changer par programmation les propriétés du zUpdateSQL associé, qui je le pensais, pouvait mener sa vie indépendamment du fait que le zQuery reste en lecture. Visiblement c'est "mal" (ou pas) le cas si l'on peut dire. (Ceci explique pourquoi je me suis intéressé à la propriété [ukInsert] du zUpdateSQL).

Bon visiblement, "l'association" n'est pas conçue pour fonctionner comme je l'attends. J'en resterai donc à mes zQuery indépendants.

Merci pour votre aide. A bientôt. Cordialement. Gilles