Discussion :

[Nafanga]

Bonjour,

Je débute dans delphi. J'utilise delphi 7 (on se moque pas, j'ai plein de composants D7 non compatibles Delphi2000), IBX avec Interbase 6.5 et me pose pas mal de questions sur l'optimisation des perf des datasets delphi:

1. Dans le cas d'un filter sur un TIBTable: est ce que
a) delphi rapatrie tous les enregistements sur le client et présente uniquement ceux correspondant aux critères du filtre ?
b) delphi execute sur le serveur le filtre et ne rapatrie que les enregistrements correspondant aux critères sur le client

2. Dans le cas d'un master/detail: est ce que
b) delphi rapatrie tous les enregistrements aussi bien du master que du details sur le client et ne présente que les details correspondant au record courant du master ?
b) delphi rapatrie les records de la dataset master puis amène uniquement les records (details) correspondant au master courant.

3. Mise à part sa simplicité d'utilisation, est ce qu'un TIB pose des problèmes de performance ? Faut_il pour une appli manipulant un volume important de données préférer systématiquement des TIBQuery à des TIBTable.

4. Refresh d'un record particulier dans un dataset
existe-il un moyen de rafraichir un record particulier d'une dataset sans rafraichir la dataset dans son intégralité ?
La methode Refresh s'appliquant à tous les records de la dataset, la méthode resynch n'étant pas mieux.


Merci pour votre aide.

Nafanga.

[rsc]

Certains éléments de réponses dans ce thread :
http://www.developpez.net/forums/vie...light=#2199063

[Nafanga]

Le thread en question parle de TTable (donc BDE).
Est le même raisonnement pour TIBTable (donc sans BDE).

Après une plongée dans la donc Interbase, Dev Guide, Working with Queries, j'en viens à la conclusion que un TIBTable rapatrie tout sur le client, ensuite on peut appliquer un filtre. Ce qui n'est pas le cas du TIBQuery/TIBDataSet qui applique le filtre (la requete SQL) sur le serveur et rapatrie ce qu'il faut ... D'où tous les gains de perf.

Quant aux master/details, le même raisonnement s'applique si on utilise des TIBQuery/TIBDataSet.

Maintenant il me manque la possibilité de rafraichir un seul record d'un dataset sans toucher aux autres. Ce qui accroitrait dramatiquement les perfs d'une appli.

Merci.

Nafanga.

[rsc]

Le thread en question parle de TTable (donc BDE).
Est le même raisonnement pour TIBTable (donc sans BDE).

Je n'en suis pas absolument sûr, mais je crois. Il y a sans doute derrière un mécanisme SQL au lieu d'être BDE, mais comme son nom 'lindique, il ramène la table.

Après une plongée dans la donc Interbase, Dev Guide, Working with Queries, j'en viens à la conclusion que un TIBTable rapatrie tout sur le client, ensuite on peut appliquer un filtre. Ce qui n'est pas le cas du TIBQuery/TIBDataSet qui applique le filtre (la requete SQL) sur le serveur et rapatrie ce qu'il faut ... D'où tous les gains de perf.

Tout à fait !

Maintenant il me manque la possibilité de rafraichir un seul record d'un dataset sans toucher aux autres. Ce qui accroitrait dramatiquement les perfs d'une appli.

Si par "rafraîchir" tu entends "mettre à jour", tu as toujours la possibilité de déclencher la mise à jour dans ta base de l'enregistrement modifié dès que tu changes d'enregistrement. C'est d'ailleurs quasi impératif dans un environnement ou plusieurs postes accèdent à la même base, sinon les gens vont sans cesse travailler sur des données périmées.

Par exemple, si tu mets à jour des fiches clients, tu as un 1er Query qui te ramène la liste de leurs noms (filtrée ou non), et un deuxième Query qui affiche toutes les données du client en cours Et tu fais tes modif sur ce 2ème Query, et tu valides avant de changer de client.

[Nafanga]

Effectivement il est possible de forcer la mise a jour du dataSet à chaque mise à jour de la base. je crois que c'est le parametre ForcedRefresh.

Le cas auquel je suis confronté est différent. J'ai une relation master/detail. Chaque enregistrement d'un Detail déclenche un trigger qui fait des traitements complexes. En particulier un des champs du Master est mis à jour.
Il s'agit pour moi de pouvoir "rafraichir" uniquement le record courant du Master afin de voir son champ modifié à l'écran.

Merci une fois de plus pour tous tes éclairages qui me permettent au passage de regler plein de petits soucis.

Nafanga.

[rsc]

Le cas auquel je suis confronté est différent. J'ai une relation master/detail. Chaque enregistrement d'un Detail déclenche un trigger qui fait des traitements complexes. En particulier un des champs du Master est mis à jour.
Il s'agit pour moi de pouvoir "rafraichir" uniquement le record courant du Master afin de voir son champ modifié à l'écran.

Justement, si ton record maître est affiché par un Query qui ne ramène que celui-ci, le Refresh ne rafraîchira que celui-ci. Ensuite, les perf dépendent :
- beaucoup des index mis en place dans ta table (tous les champs figurant dans une clause WHERE ou ORDER BY devraient être indexés)
- quelquefois de la manière de formuler ta requête

[Nafanga]

àest tout mon problème ... en fait le master est un DBGrid donc une liste de record et je veux justement rafraischir que le record courant du master.

Merci
Nafanga.