Discussion :

[TicTacToe]

Bonjour

Voila quelques temps que je suis en train de reconstruire ma base de développement et d'outils en fmx.
Coté BD, j'ai choisi Firedac puisque c'est visiblement ce qui est préconisé à l'heure actuelle.

Je viens de D2007/BDE/Paradox/TTable/DBGrid, qui bien qu'obsolète fonctionne encore à merveille même sur des volumes conséquents à mon échelle (45 users / tables avec > 5 Millions de lignes), avec des désavantages bien sur mais c'est pas le sujet, et je suis en mode TSE ce qui arrange aussi les choses vu que la base n'est pas client/Serveur.

Très bonne idée d'automatiser le mappage TControl <-> DB avec LiveBinding - même si un peu lourd - afin d'éviter de dédoubler les TControls orientés données ou pas. (TEdit/TDBEdit, TCheckBox/TDBCheckbox etc...).

MAIS car bien sur il y a un mais... ce mappage est très bien lorsque les données à mapper sont légères (comme les TControl pour un enregistrement unique style TEdit par exemple).

Etant donné que j'ai choisi FMX, je suis bien obligé d'abandonner la TDBGrid pour la TStringGrid.
Cela m'a vraiment intrigué. Bizarre ce changement car ce sont 2 composants très différents l'un de l'autre dans la philosophie.
Un contient des données, l'autre non. Et cela est confirmé, c'est un peu la catastrophe à moins que vous m'éclairiez (et j'en ai besoin) !

D'un coté, avec mon vieux D2007/BDE/TDBGrid, j'affiche instantanément 10000 lignes dans une TDBGrid, et je me positionne ou je veux instantanément, (bien que je suis conscient que seuls les datas réellement affichées sont stockées et chargées dans cette zone tampons pour affichage au fur et à mesure par une mécanique de 'paging')

De l'autre... Le LiveBinding sur la TStringGrid... très lente (forcément car chargement des 10000 lignes dans la grille!), ca pompe de la mémoire, ca pompe sur le CPU. (bien qu'objectivement assez rapide pour le boulot que ca fait mais c'est pas le bon boulot!).
Pas de paging prévu ? c'est pourtant plus qu'à la mode avec les mobiles et les défilements d'informations (java/android est blindé de callback dans ce but)!

Et je ne parle pas du fetching par bloc, ce n'est pas la même chose. Car l'accès aux données d'une requête en FetchAll est rapide elle, donc ça ne résoudra rien, j'ai essayé.

De plus j'ai bien remarqué qu'il faut abandonner le TFDTable pour un TFDQuery sinon les perfs sont en chutes libres, ca m'arrange pas car il était très pratique de créer les Fields manuellement dans le composant Table afin d'optimiser l'accès plutôt que par un FieldByName qui effectue une recherche dans les champs (enfin ca, c'est peut être optimisé j'ai pas vérifié).

A moins d'avoir loupé une étape, et je l'espère car je suis un peu désespéré, est-ce qu'une solution existe pour afficher une grille de 10000 lignes venant d'une table de manière instantanée (car seule une 50 lignes maxi sont en général visibles en même temps sur l'écran) dans une grille sous FMX ???

Quelle régression si ce n'est pas le cas... ou alors il faut qu'il y ait une vraie raison technique pour ne pas l'avoir fait, laquelle ?

J'ai pas mal cherché, j'avais un petit espoir avec TMS, mais non, leur Grid repose sur le même système.

Merci pour vos commentaires

[ALWEBER]

Tu as regardé du côté de TFDMemTable pour gérer en tampon tes 10000 lignes avant de les envoyer dans ton TStringGrid.

[Barbibulle]

+1 pour ALWEBER

je ne connais pas bien FMX mais je m'orienterai également vers TFDMemTable qui permettra de rapatrier les données dans une table mémoire. (Et pourquoi pas utiliser le mode déconnecté....)

De plus j'ai bien remarqué qu'il faut abandonner le TFDTable pour un TFDQuery sinon les perfs sont en chutes libres, ca m'arrange pas car il était très pratique de créer les Fields manuellement dans le composant Table afin d'optimiser l'accès plutôt que par un FieldByName qui effectue une recherche dans les champs (enfin ca, c'est peut être optimisé j'ai pas vérifié).

Après avoir défini la requête dans le FDQuery clic droit puis "Editeur de champs" puis dans la petite fenêtre qui s'ouvre CTRL+A pour ajouter des champs ou CTRL+N pour créé un champ (calculé par exemple).
Les champs créés par CTRL+A auront un nom de type FDQueryNomChamp.

[TicTacToe]

Merci pour vos réponses

Barbibulle, oui merci pour les fields dans les FDQuery, j'ai été un peu vite

Par contre pour TFDMemTable, je vais toujours essayer mais sans conviction puisque ce qui prend du temps c'est visiblement la recopie des données dans la StringGrid via le LiveBinding.
Faire intervenir une FDMemTable, c'est ajouter un élément intermédiaire entre le FDQuery et la TStringList, mais sait-on jamais... et puis ca va pomper encore un peu plus de mémoire aussi j'imagine

[Barbibulle]

Par contre pour TFDMemTable, je vais toujours essayer mais sans conviction puisque ce qui prend du temps c'est visiblement la recopie des données dans la StringGrid via le LiveBinding.
Faire intervenir une FDMemTable, c'est ajouter un élément intermédiaire entre le FDQuery et la TStringList, mais sait-on jamais... et puis ca va pomper encore un peu plus de mémoire aussi j'imagine

Heu oui à y réfléchir a mon avis ça ne servira à rien.

Il y a déjà dans le TFDQuery une mise en cache similaire à TFDMemTable. Donc le test avec le FetchAll a permet de tout récupérer.

C'est quelle version de Delphi ?

Moi j'ai souvenir d'avoir testé les FMX il y a pas mal de temps et j'avais constaté que l'interface était moins véloce que du VCL mais bon je n'ai peut être pas les bonnes pratiques...

Et pour commencer voir pour ne pas rapatrier les 10 000 lignes...

Je regarderai dans les options FetchOptions du composant TFDQuery voir s'il y a moyen de récupérer de manière paginé ou du moins par bloc piloté par la stringgrig/livebinding...

[Barbibulle]

Peut etre en mettant

Code :

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

FDQuery.FetchOptions.AutoFetchAll = afDisable;

et en laissant le mode en fmOnDemand

[TicTacToe]

oui pour les FDMemTable je vais quand même tenter ne serait-ce que pour apprendre à les utiliser, car cela manquait vraiment sous le BDE en D2007.

Pour la version de Delphi c'est dans le sujet

Pour les options Fetch, c'est ce que j'ai tenté en 1er (voir dans mon sujet de départ) en essayant de paginer moi même de manière grossière.

Mais je n'ai pas trouvé cela satisfaisant au niveau vitesse, et de plus si je souhaite me positionner directement sur l'avant dernière ligne (au hasard ),
il faut faire autant de fetch que nécessaire (et au final, 10 fetch de 1000 lignes est finalement bien plus lent qu'un seul optimisé de 10000).
Le rendu final est assez médiocre coté utilisateur, temps d'attente désagréable par a-coup.

Alors peut-être qu'en creusant il serait possible de le faire, mais c'est un effort considérable alors qu'il y a tant d'outils performant dans ces nouvelles moutures.
Ce serait dommage de ré-inventer la roue!

Si cela n'est pas possible (d'avoir l'équivalent d'une mécanique DBGrid), cela m’intéresse aussi de le savoir, je ré-orienterai ma stratégie de dév...

[Barbibulle]

Peut etre en mettant

Code :

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

FDQuery.FetchOptions.AutoFetchAll = afDisable;

et en laissant le mode en fmOnDemand

Nos messages se sont croisés.

Et oui c'est écrit en gros et gras XE8 !

[ALWEBER]

oui pour les FDMemTable je vais quand même tenter ne serait-ce que pour apprendre à les utiliser, car cela manquait vraiment sous le BDE en D2007.
.

Je vais essayer de retravailler un des exemples que j'utilise pour mes cours.

[cantador]

Bonjour,

affichage rapide de 10000 lignes dans un TStringGrid ?
ça va être chaud..

j'ai trouvé ça, à tout hasard et pas testé :

http://www.rosinsky.cz/delphi/dbstringgrid.html


cantador

[TicTacToe]

@cantador, merci pour le lien mais ce sont des composants VCL...

Alweber, merci mais tu peux laisser tomber. Comme prévu, introduire un TFDMemTable ne change rien du tout.

Le temps de passage FDQuery->FDMemTable est quasi instantané, FDMemTable->StringGrid via LiveBinding reste long.
Tout ca est très logique...

[SergioMaster]

Bonjour,

j'ai trouvé ça, à tout hasard et pas testé

H.S. il s'agit le sujet c'est les grilles FMX pas VCL, ce DBStringGrid est présenté avec D7 !

pour reprendre la question de départ, moi aussi je me suis trouvé confronté à ces questions existentialistes
"FMX or not FMX that is the question"
et me suis heurté (même si depuis le temps je n'ai plus de marques ) à ces mêmes questions (avec XE2 puis XE4) que TictacToe soulèvent (le caret, les grilles) et encore n'a t-il pas abordé l'équivalent DBlookupCombobox ou un TMaskEdit ou ... j'en passe

du coup je me suis imposé plusieurs règles mais en ce qui concerne plus particulièrement les données : 'peu de trafic' est inscrit au fer rouge, "Query plutôt que Table" m'était déjà une règle d'or mais j'avais eu du mal avec le blocage du nombre de lignes récupérées avec la version Firedac XE4

Constatations : Firedac s'est amélioré depuis son apparition, les livebindings pas vraiment, l'éditeur de style non plus

[TicTacToe]

De ce que je constate, mais j'ai pas passé des heures à analyser la mécanique précise,
il pourrait manquer une option 'visible/OndDemand' dans la gestion LiveBinding pour que le chargement puisse se faire au vol, "charger seulement si visible".
Comme le fetch/OnDemand, le temps total de chargement serait bien plus long, mais coté "impression utilisateur", ce serait bien plus rapide.

Et il faut bien que cette option soit au niveau de LiveBinding, car d'autres composants Liste, comme TListView etc... sont soumis aux même règles: tout charger lors
de l'activation LiveBinding.

Ce serait peut-être plus judicieux coté embardero (idera?), d'agir à ce niveau plutôt que de ré-introduire la DBGrid et ainsi garder la même logique partout.
(car le même problème se pose pour les autres listes aussi)


J'ai également remarqué quelque chose de bizarre sur le LiveBinding et StringGrid.
(mais je le met en tout petit car je suis limite HS)

Construction de départ
TFDQuery -> TDataSource -> TBindSourceDB -> TBindList.TLinkGridToDataSource( MaDataSource, MaStringGrid)
avec TLinkGridToDataSource.AutoActivate = False
ET TLinkGridToDataSource.Active= False
5000 lignes sur FDQuery

traitement test: 5000 random FindKey sur TFDQuery qui est indexée (et avec un FDQuery.DisableControls ...)

traitement test au départ: < 100 ms
Activation de TLinkGridToDataSource.Active := True (remplissage des données LiveBinding = 3.2 sec)
Traitement test: 9 sec (!)
Désactivation TLinkGridToDataSource.Active := False (instantané)
Traitement test: toujours 9 sec (!) alors qu'il n'y a plus de liaison (normalement) avec la TSTringGrid qui est vide
(et si réactivation du TLingGridToDataSource -> re 3.2 sec, aucun cache n'est gardé)

En fait, le traitement test revient à moins de 100 ms si on "coupe" la liaison en amont
TDBBindSource.DataSource = nil ...
donc bien qu'on désactive TLingGridToDataSource, il se passe encore des choses lorsque d'un traitement sur le dataset... donc bizarre

[Paul TOTH]

Bonjour,

Alors j'ai regardé cela en détail car si sous Windows avec une bonne machine on ne voit pas de problème, sur mobile le chargement d'une table de quelques milliers d'enregistrement pose en effet un problème de performance.

Le problème principal c'est que LiveBinding n'est pas orienté BDD au départ, c'est un mécanisme qui permet de relier des propriétés objets sans présupposé. Du coup le lien vers un TStringGrid ou une ListView se contente en effet de copier TOUS les enregistrements dans le composant, là ou une DBGrid venait chercher un nombre limité d'enregistrement "au besoin".

Dans la logique de LB, le composant ne sait pas qu'il a affaire à un BDD, en fait il ne sait même pas que c'est LB qui le manipule. Et LB ne sais pas grand chose sur le composant destinataire...du coup il est assez compliqué de mettre en un mécanisme de lazy loading.

Je n'ai pas ça ce jour de solution toute faite, ce que je recommande du coup c'est de ne pas afficher une grille de données (sauf pour un nombre réduit de données). Du coup, pour les grosses bases, cas ou l'affichage d'une liste - même virtuelle - de milliers d'enregistrement n'a pas bcp d'intérêt, il faut mettre un champ de recherche afin de limiter le nombre de retour et éventuellement proposer un bouton "Plus de données" pour afficher la suite si là encore on a bcp de données. Le tout ne se faisant plus sous LB et pouvant être placé dans un Thread.

On pourrait aussi imaginer une navigation par page, on rempli une première page d'enregistrement et sur un glissé à gauche on affiche la suite...glissé à droite on revient en arrière.

[ALWEBER]

Voilà un petit exemple

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
...
type
  TForm2 = class(TForm)
    FDMemTable1: TFDMemTable;
    BindSourceDB1: TBindSourceDB;
    BindingsList1: TBindingsList;
    StringGrid1: TStringGrid;
    LinkGridToDataSourceBindSourceDB1: TLinkGridToDataSource;
    procedure FormCreate(Sender: TObject);
  end;
 
var
  Form2: TForm2;
 
implementation
 
{$R *.fmx}
 
procedure TForm2.FormCreate(Sender: TObject);
var
  i1: integer;
  st1: string;
begin
  BindSourceDB1.Dataset := nil ;
  st1 := 'ABCDEFABCDEFABCDEFABCDEFABC';
  with FDMemTable1 do
  begin
    FieldDefs.Add('ID', ftInteger);
    FieldDefs.Add('Code', ftString, 10);
    FieldDefs.Add('Name', ftString, 50);
    CreateDataSet;
    with Indexes.Add do
    begin
      Name := 'ID';
      Fields := 'ID';
      Options := [soPrimary] ;
      Active := True;
    end;
  end;
  for i1 := 1 to 100000 do
  begin
    FDMemTable1.Append;
    FDMemTable1.Fields[0].AsInteger := i1;;
    FDMemTable1.Fields[1].AsString := 'N' + i1.ToString;
    FDMemTable1.Fields[2].AsString := st1;
    FDMemTable1.Post ;
  end;
  FDMemTable1.IndexName := 'ID' ;
  FDMemTable1.IndexesActive := true ;
  FDMemTable1.SetRange([1], [100]);
  BindSourceDB1.Dataset := FDMemTable1 ;
end;
 
end.

Après en jouant sur le SetRange il y a de quoi avoir une bonne réactivité.

Code :

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

1
2
3
4
 
  BindSourceDB1.Dataset := nil ;
  FDMemTable1.SetRange([100], [200]);
  BindSourceDB1.Dataset := FDMemTable1 ;

[TicTacToe]

@Paul
Merci pour tes observations.

Alors j'étais sur qu'à un moment donné on allait me dire "charge moins de lignes"... Mais non ce n'est pas le sujet et je ne souhaite pas polémiquer autour de cela.
et c'est vraiment ce que je souhaite pour essayer de recréer un nouveau noyau qui est basé sur un affichage qui peut comporter beaucoup de lignes puis de cibler ce qui nous
intéresse, soit en se positionnant dessus, soit en filtrant (via index,filter etc...). Et pas l'inverse en filtrant de manière drastique dès le départ sans avoir une vue globale et de navigation libre.

et même en descendant à 5000 lignes avec peu de colonnes, je suis a 3.2sec de chargement (pour donner une idée). En partant du principe de diminuer le nombre de lignes je n'arriverai pas à mes fins. Un affichage réactif doit descendre en dessous de la demi seconde (donc 780 lignes maxi et pour peu que j'augmente le nombre de colonnes - probable! - il faudrait encore que je descende)
-> non, quelque part ce n'est pas à moi d'adapter un "bon" nombre de lignes alors qu'il y avait des solutions existantes et qui n'ont pas été reprises. Même si LB par d'un (très) bon sentiment.

(mais bon là j'ai déjà commencé à polémiquer désolé)

Donc pour revenir au sujet, LB et StringGrid.

StringGrid ne sait pas qu'il est piloté par LB, donc je concois que ce n'est pas du coté StringGrid qu'il peut y avoir une amélioration. (Bien qu'il pourrait y avoir une information générique au niveau TControl de liaison avec LB tant LB devient omniprésent...)

Cependant nous avons cet ensemble d'informations:
- il y a un élément TBindSource -> a connaissance de la table de départ
- il y a un élément TLingGridToDataSource -> typé, concu pour relier un StringGrid et un TBindSource (ou autre Datasource) -> il a connaissance de ces éléments
- Le TStringGrid a tout un tas d'évènements utiles (onCellSelect, onVScrollChange... ) qui peuvent être interceptés par le LB une fois initialisé !

Avec tous ces éléments, il me semble parfaitement réalisable d'établir un paging ou "Lady loading" pour reprendre tes termes. De plus les éléments déjà chargés le reste et sert de cache.
(Tant pis pour la RAM au point ou on en est).

voila, je ne sais pas si les prochaines versions essaierons de résoudre ce type de problème qui est à mon sens une régression dans l'affichage de données DB, même s'il LB est très puissant et apporte énormément de chose pour nous simplifier la vie, et qu'il évite également de l'écriture de composants similaires (TDBEdit/TEdit).

@Alweber
Mais on reste dans le principe de diminution du nombre de lignes. Très peu de colonnes. et avec un SetRange de 100 lignes, heureusement qu'il y a de la réactivité en copie

[TicTacToe]

Alors j'ai trouvé une solution qui est capable d'afficher instantanément dans une TStringGrid une table d'autant de milliers de lignes qu'on souhaite

Cette méthode initialise la grille, en nombre de colonnes et de lignes souhaitées. C'est instantané même pour des milliers de lignes

Initialisation de la grille:

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
procedure TFrTest.ButtonInitGrilleClick(Sender: TObject);
var
   i: Integer;
   Column: TStringColumn;
begin
     chronodebut;
     StringGrid1.BeginUpdate;
     for i := 0 to FDTable.FieldCount - 1 do
       begin
       Column := TStringColumn.Create( Self );
       Column.Header := FDTable.Fields.Fields[ i ].FieldName;
       Column.Parent := StringGrid1;
       end;
     StringGrid1.RowCount := FDTable.RecordCount;
     StringGrid1.EndUpdate;
     chronofin;
end;

Chargement des lignes visibles si non déjà chargées

Code :

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

1
2
3
4
5
6
7
8
9
10
procedure TFrTest.VScrollChange(Sender: TObject);
var
   i, j: Integer;
begin
     for i := StringGrid1.TopRow to StringGrid1.BottomRow do
       if StringGrid1.Cells[ 0, i ] = '' then
         if FDTable.FindKey( [ i ] ) then
           for j := 0 to FDTable.FieldCount - 1 do
             StringGrid1.Cells[ j, i ] := FDTable.Fields[ j ].AsString;
end;

Alors tout est en dur, et ma 1ere colonne est une clef qui concorde avec ma clef DB. Il faudrait se positionner sur la table avec RecNo (si ca existe toujours).
De plus, VScrollChange n'est pas forcément l'évènement adéquoit, il faut que je creuse.

Mais dans le principe, cela fonctionne parfaitement et présente à l'utilisateur une table avec toutes les lignes. Le chargement des lignes non déjà chargées est bien sur quasi instantanés car il ne peut y en avoir au maximum que celle qui sont visibles (donc pas beaucoup).

Ce système ne passe pas par LB, donc il faut gérer l'autre sens (modification de la grille -> modification des datas) le cas échéant. Mais dans mon cas je le fait rarement à ce niveau.

Voila... si ça peut en dépanner certains qui sont dans le même cas que moi !

[TicTacToe]

Suite et fin

La solution ci-dessus est réalisable mais il faut quand même ré-inventer la roue (synchroniser le curseur table et grille, gérer les calc, les formattages etc...... et je suis sur d'en découvrir au fur-et-à mesure). C'est très enrichissant de ré-inventer la roue mais parfois un peu contre-productif.

TMS l'a déjà fait visiblement -> TMSFMXLiveGrid
Que l'on peut faire fonctionner avec LB et qui semble ne charger QUE ce qui est visible (en parcourant la grille, la RAM ne monte pas donc cela doit recharger à chaque fois mais c'est mieux que charger l'ensemble déjà).

100 000 lignes affichées instantanément!

Dommage qu'il faille faire appel à un composant tiers (et payant)...

Allez, ce sera pour Delphi X11

[Paul TOTH]

Suite et fin

La solution ci-dessus est réalisable mais il faut quand même ré-inventer la roue (synchroniser le curseur table et grille, gérer les calc, les formattages etc...... et je suis sur d'en découvrir au fur-et-à mesure). C'est très enrichissant de ré-inventer la roue mais parfois un peu contre-productif.

TMS l'a déjà fait visiblement -> TMSFMXLiveGrid
Que l'on peut faire fonctionner avec LB et qui semble ne charger QUE ce qui est visible (en parcourant la grille, la RAM ne monte pas donc cela doit recharger à chaque fois mais c'est mieux que charger l'ensemble déjà).

100 000 lignes affichées instantanément!

Dommage qu'il faille faire appel à un composant tiers (et payant)...

Allez, ce sera pour Delphi X11

hum...je serais curieux de savoir comment il font ça

j'ai tenté de le faire, mais IBindListEditor est particulièrement pauvre comme interface, elle propose une méthode FillList() avec un paramètre IScopeRecordEnumerator qui ne donne pas accès au DataSet mais unique à la liste des record...c'est cette méthode qui rempli les ListView par exemple.

[cantador]

@SergioMaster

H.S. il s'agit le sujet c'est les grilles FMX pas VCL, ce DBStringGrid est présenté avec D7 !

houpppssss !

cantador