Discussion :

[franckcl]

FireDAC / Delphi 10.3.3

Bonjour,

J'ai une TTable dans laquelle j'ai rajouté le filtre suivant:

Code :

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

1
2
3
4
5
 
  FDTable1.Filter:='(hash_config='''+Hashconfig+''')'+
                   ' AND (datetime >= {d ' + (FormatDateTime('yyyy-mm-dd', DateTimeFrom.Date))+'})'+
                   ' AND (datetime < {d ' + (FormatDateTime('yyyy-mm-dd', incDay(DateTimeTo.Date)))+'})';
  FDTable1.Filtered:=true;

Avant l'ouverture, je fais une pagination:

Code :

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

1
2
3
4
 
  FDTable1.FetchOptions.RecsSkip := 0;
  FDTable1.FetchOptions.RecsMax := 100;
  FDTable1.open;

et la pagination n'est pas prise en compte alors que si je passe Filtered=false, ça marche.
Cette contrainte n'est pas dans la doc: http://docwiki.embarcadero.com/RADSt...gnes_(FireDAC)

Est-ce que j'ai loupé quelque chose ?
Merci

[SergioMaster]

Bonjour,

Est-ce que j'ai loupé quelque chose ?

Je ne sais pas mais cela me parait logique pour filtrer la table il faut lire tous les enregistrements.
Perso j'ai toujours préféré les Querys (qui elles n'auront pas ce problème de pagination)

[franckcl]

Perso j'ai toujours préféré les Querys (qui elles n'auront pas ce problème de pagination)

Oui je peux comprendre que les Query semblent plus facile d'utilisation grâce au champ SQL mais j'ai besoin de recalculer des colonnes et en utilisant les fonctions SQL je n'arrive pas à obtenir ce que je veux.

[SergioMaster]

Mais même avec une Query on peut ajouter des champs calculés (et même des aggrégats avec Firedac)

en utilisant les fonctions SQL je n'arrive pas à obtenir ce que je veux.

cela dépend beaucoup du SGBD

[franckcl]

Entre temps, j'ai refais des tests et effectivement j'arrive à obtenir les colonnes, le problème c'est que c'est énormément plus long qu'en utilisant les FDtables mais vraiment !
Cependant comme la fonction de pagination fonctionne avec un Query, je vais voir si je ne m'oriente pas vers cette solution quand même....pas simple quand on traite des tables de plusieurs dixaine de millions d'enregistrements.

[ShaiLeTroll]

Je ne connais pas TFDTable ni TFDQuery mais comme est traduit le filtre** ?
Selon le provider, le filtre est converti en SQL et finalement le Table c'est juste une Query simplifié, dans d'autres, c'est une récupération des données et fitrer en local.

Le premier va solliciter le serveur surtout si il n'y a pas d'INDEX*
Le second va solliciter moins le CPU du serveur mais plus de bande passante et la mémoire du client

Selon votre SGBD, vous avez plusieurs méthodes pour lancement un SQL, c'est les options du Curseur, il peut être bi ou unidirectionnel, [a]synchrone, paginé ou non.
Le choix influe énormément selon la volumétrie et les optimisations effectué par le DBA.
J'ai pu constaté avec ADO qu'il y avait un problème dans l'implementation Delphi d'un curseur client (où justement cela serait un filtre local)

* il est parfois plus long à éxécuter un SQL mal optimisé que de récupérer 10000 même l'on n'en affiche que 10 répondant au filtre.

EDIT
** on a un début de réponse

TFDTable et filtrage
- En mode Fenêtre Données dynamiques, TFDTable utilise le filtrage côté serveur (WHERE) dans les situations suivantes :

Pour la propriété Filter. Notez que le contenu de la propriété Filter est envoyé à une base de données tel qu'il est. Vous pouvez utiliser les séquences d'échappement FireDAC pour rendre une expression compatible avec un SGBD et avec le moteur d'expression local.
Pour un TFDTable détail dans une relation maître-détail.
Quand une plage de valeurs est appliquée à un TFDTable.

- En mode Fenêtre Données dynamiques, TFDTable utilise le filtrage côté client pour :

L'événement OnFilterRecord.
La propriété FilterChanges.