Discussion :

[NABIL74]

Bonjour,

J'ai une application de gestion. Dans ma BDD, il y a un TTable qui contient des millions d'enregistrements.
ça prend du temps pour les charger, alors, je veux afficher une fiche pour renseigner l'utilisateur que les enregistrements sont en train de se charger (voir l'image jointe). Après que la table soit ouverte, je ferme cette form2



Le code du bouton de la Form1:

Code :

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

1
2
3
4
Form2.Showmodal;
Table1.open;
Sleep(1000);
Form2.Close;

La Form2 s'affiche mais la Table1 ne s'ouvre pas et la Form2 reste tout le temps affichée.

J'ai testé après :

Le code du bouton de la Form1:

Code :

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

1
2
Form2.Showmodal;
Table1.open;

Et dans la Form2, j'ai mis un TTimer qui vérifie si la Table1 est déjà ouverte, si c'est le cas, on ferme la Form2.

Delphi XE5 + Firebird 2.5.

J'ignore si je vous ai bien expliqué ce soucis.
Merci pour votre aide.

[tourlourou]

Lors de l'appui sur le bouton de la Form1, son code affiche la Form2 modale et attend qu'elle soit fermée pour continuer l'exécution du code. Donc Tabl1.Open n'est exécuté qu'après fermeture de Form2, qui n'intervient que lorsque la table est ouverte, cad jamais !

En remplaçant le ShowModal par un Show, l'inconvénient serait levé, mais sans avoir l'avantage du Modal...

En déplaçant le code d'ouverture de la table dans le OnShow de Form2, tu devrais t'en sortir !

[retwas]

Utilise une Task pour afficher la form et charger les données, puis utilisent le WaitForAll pour la cacher.

En revanche il faut un Delphi XE7 minimum.

[SergioMaster]

Bonjour,

un Task n'existe peut être pas pour les versions antérieurs mais qu'est-ce sinon une encapsulation d'un Thread voir FAQ

La vraie bonne question cependant est pourquoi charger toute une table de, je cite, "des millions d'enregistrements". Il est évident qu'un utilisateur ne lira jamais tout et un écran ne peut qu'en afficher quoi ? une trentaine à tout casser !
Bref tout dépend des composants utilisés mais récupérer tout les enregistrements me semble inadéquat.

Par exemple , avec un TZTable il y a une propriété FetchRow (=0 par défaut) si tu mets 100 seuls les 100 premiers enregistrements seront récupérés dans un premier temps, le reste (100 par 100) sera récupéré au fur et à mesure des besoins

[NABIL74]

Bonjour,
Merci de vos réponse.

@ tourlourou, j'ai testé ce que tu m'a conseillé (dans le OnShow), le résultat c'est que le Form2 reste invisible et ne s'affiche qu'après que Table soit ouverte .

@ Serge:

La vraie bonne question cependant est pourquoi charger toute une table de, je cite, "des millions d'enregistrements". Il est évident qu'un utilisateur ne lira jamais tout et un écran ne peut qu'en afficher quoi ? une trentaine à tout casser !

L'application tourne sous réseau. L'utilisateur de chaque poste client ajoute plus de 1500 enregistrements par jour.
On a besoin de faire des recherches sur tels records, des filtres,...

Si je mets dans la propriété "Fetch" (comme avec la bdd MsAccess,...) de ZTable 1000 par exemple, ça se charge rapidement, mais l'inconvénient c'est quand on veut ajouter un nouvel enregistrement à la Table, les données doivent êtres chargées. C'est ça mon soucis.

[tourlourou]

Pardon, le OnShow se produit juste avant l'affichage...

Mets le code dans le OnActivate, qui se situe juste après.

[NABIL74]

Hello,
J'ai mis e code dans le OnActivate, la Form2 reste figée (freeze).

[guillemouze]

L'application tourne sous réseau. L'utilisateur de chaque poste client ajoute plus de 1500 enregistrements par jour.
On a besoin de faire des recherches sur tels records, des filtres,...

Si je mets dans la propriété "Fetch" (comme avec la bdd MsAccess,...) de ZTable 1000 par exemple, ça se charge rapidement, mais l'inconvénient c'est quand on veut ajouter un nouvel enregistrement à la Table, les données doivent êtres chargées. C'est ça mon soucis.

Je suis pas spécialiste, mais je ne vois pas ce qui gêne dans ce cas. Depuis quand il faut charger une table pour y ajouter un enregistrement ?

[SergioMaster]

Si je mets dans la propriété "Fetch" (comme avec la bdd MsAccess,...) de ZTable 1000 par exemple, ça se charge rapidement, mais l'inconvénient c'est quand on veut ajouter un nouvel enregistrement à la Table, les données doivent êtres chargées. C'est ça mon soucis.

mais c'est parce que tu utilises un ZTable alors que avec un ZQuery (lié à un TZUpdateSQL) tu n'aurais pas ce soucis. De plus je dirais que tu devrais séparé l'affichage d'un ensemble d'enregistrements (ZReadonlyQuery) de la saisie (un ZQuery sur un seul enregistrement) il ne faut plus raisonner en terme de table quand il y a tant d'enregistrements et qu'en plus c'est en réseau. (Fini le temps de Paradox) .

Sinon : voici une solution qui réglera ton problème et ce sans forme supplémentaire.

Utilise un TPageControl avec un volet (tab) masqué (celui de l'attente) avant l'ouverture de la table tu bascules le pagecontrol sur ce volet, à la fin de l'ouverture tu rebascule sur le volet contenant le reste de ton application
autre solution, si ta table est dans un datamodule c'est plus simple, tu peux encore passer par un forme modale (en gérant sa cloture quand même : impossible de fermer la fenêtre tant que la table n'est pas ouverte) et c'est cette forme, à la création qui ouvre la table contenue dans le datamodule donc accessible par les autres formes après

[tourlourou]

OK... donc solution déjà suggérée par retwas et Serge = mise en thread du chargement

Pour la BDD, plusieurs millions d'enregistrements, ajout de plus de 1500 enregistrements par utilisateur et par jour : à quel moment ça va péter, compte tenu des technologies et techniques de codage employées ?

[SergioMaster]

Pour la BDD, plusieurs millions d'enregistrements, ajout de plus de 1500 enregistrements par utilisateur et par jour : à quel moment ça va péter, compte tenu des technologies et techniques de codage employées ?

AMHA assez vite si Nabil utilise une table, en multi utilisateurs il va falloir gérer les rafraichissements de chaque poste à chaque ajout, et je ne parle même pas des problèmes de transaction !

[NABIL74]

Je suis pas spécialiste, mais je ne vois pas ce qui gêne dans ce cas. Depuis quand il faut charger une table pour y ajouter un enregistrement ?

@ guillemouze: Supposons que j'ai mis "Fetch" à 1000. Quand on veut ajouter un nouvel enregistrement(avec un append) dans un TTable, on va se pointer sur le dernier enregistrement de TTable non? Donc, tous les enregistrements (dans mon cas c'est quelques millions) seront chargés, j'ai déjà fait ce teste avant de poster sur le forum.

@ Serge :

mais c'est parce que tu utilises un ZTable alors que avec un ZQuery (lié à un TZUpdateSQL) tu n'aurais pas ce soucis. De plus je dirais que tu devrais séparé l'affichage d'un ensemble d'enregistrements (ZReadonlyQuery) de la saisie (un ZQuery sur un seul enregistrement) il ne faut plus raisonner en terme de table quand il y a tant d'enregistrements et qu'en plus c'est en réseau. (Fini le temps de Paradox) .

Oui, c'est un bon raisonnement.

Utilise un TPageControl avec un volet (tab) masqué (celui de l'attente) avant l'ouverture de la table tu bascules le pagecontrol sur ce volet, à la fin de l'ouverture tu rebascule sur le volet contenant le reste de ton application

Je vais testé cela . J'ai fait un teste avec un Tlabel (chargement des données...)+ JvWaitingGradient, l'application reste figée.

Pour la BDD, plusieurs millions d'enregistrements, ajout de plus de 1500 enregistrements par utilisateur et par jour : à quel moment ça va péter, compte tenu des technologies et techniques de codage employées ?

@ tourlourou : ça pète lors du lancement de l'application et sur le rafraichissement des données.

Pour les threads, j'ai pas travaillé avec avant...

[SergioMaster]

Quand on veut ajouter un nouvel enregistrement(avec un append) dans un TTable, on va se pointer sur le dernier enregistrement

la question est alors mais pourquoi diable un append ! un insert est bien mieux

[NABIL74]

Bonsoir,

Oui Serge, j'ai testé avec un insert, c'est bien. Le soucis, c'est que lors d'une recherche (locate par exemple), ça prend du temps(parcourir tout le TTable).

[SergioMaster]

Bonjour,

mais ton erreur est là

c'est que lors d'une recherche (locate par exemple), ça prend du temps(parcourir tout le TTable).

faire une recherche dans une table aussi grosse sera rapide avec une Query (pour peu que les colonnes de recherche soient indexées cela le sera encore plus).
Tu es encore trop "Paradox" dans ta logique

[NABIL74]

Bonjour,

mais ton erreur est là

faire une recherche dans une table aussi grosse sera rapide avec une Query (pour peu que les colonnes de recherche soient indexées cela le sera encore plus).
Tu es encore trop "Paradox" dans ta logique

Bonjour,
Merci pour tes conseilles Serge .
- Voilà, j'ai remplacé "locate" par une recherche D'un TQuery et c'est beaucoup plus rapide!!
- J'ai mis la propriété "fetchrow" à 1000 et au lancement de l'application, ça se passe sans soucis...

Merci à tous pour votre aide .

Bonne journée.

Nabil