Discussion :

[Invité]

Bonjour,

Est-il possible de faire une espèce de "Fetch partiel" avec une DbGrid ?

J'ai une table mySQL (distante) importante aussi bien en nombre d'enregistrements qu'en longueur de chaque enregistrement... Dans 90% des cas, l'utilisateur a besoin de la (des) dernière(s) modification(s) sur les enregistrements... (un peu comme le forum).

Si j'utilise une chaine Dataset --> DbGrid habituelle, le temps de latence entre l'émission de la requête et l'affichage dans la dbGrid est très important... car je ne peux pas me limiter à une portion de la table (il reste les 10% qui veulent engager des opérations sur plus d'enregistrements). J'ai cherché une méthode pour dispenser les 90% du temps de latence sans évidemment pénaliser les 10% qui ont besoin d'une table complète (et pour qui évidemment il faudra patienter dans tous les cas).

Pour l'instant, mon meilleur (et seul) résultat est l'utilisation de 2 (z)Query et 2 StringGrids (dont une invisible)... La première affiche quasi-instantanément les 100 premiers enregistrements. La seconde charge le "reste" en tâche de fond (multi-thread). Tant que le travail de la seconde n'est pas terminé, les filtres et tris sont bloqués sur la première StringGrid. "Dès" que la seconde est remplie, elle complète la première et les filtres et tris sont débloqués... C'est lourd au niveau programmation (pas tellement le thread) mais les StringGrids à la place des dbGrids ... mais je n'ai trouvé que cette méthode...

...car j'ai essayé initialement la même méthode avec 2 dbGrids (donc 2 datasets) superposables. L'idée était la même : 1ère dbGrid immédiatement active et visible tant que 2nde pas "complètement" remplie... puis 2nde visible et 1ère invisible et désactivée après resynchro des sélections... Mais pour une raison que je crois comprendre maintenant, la 2ème chaine dataset-->Dbgrid (qui elle charge toute la table) bloque l'affichage de la première (ou toute autre activité)... J'obtiens finalement la même "ergonomie" (ie non pseudo-parallèle) que si j'utilise classiquement un seul dataset-->dbgrid. En échec, j'ai donc laissé tomber l'histoire des 2 dbgrids avec chacune son propre dataset.... et testé avec 2 StringGrids pour identifier le problème. En réalité, il n'y a pas de "problème" sauf conceptuel de ma part et je doute maintenant que cela puisse fonctionner ainsi (ie avec les 2 dbGrids) : avec la chaine zQuery-->DbGrid, l'utilisation des threads n'est pas adaptée du fait que le zQuery reste "en prise constante" (et que donc son travail ne se termine "jamais") sur la dbGrid et sur la table... donc il reste en quelque sorte "définitivement parallèle" ... alors que dans le cas zQuery+StringGrid, le zQuery effectue son travail de chargement puis se ferme... comme le thread qui a ainsi fait (parallèlement) son travail de mise à jour... On revient alors à la "séquence principale"...

Mais je me disais que je passais peut-être quand même à côté de quelque chose. En dehors du multi-threading, serait-il possible d'avoir le même "rendu" avec une seule dbGrid ? Sans trop y croire toutefois : il faut 2 requêtes différenciées pour obtenir 2 résultats du serveur... Un immédiat et l'autre qui nécessitera plus de temps... Et une dbGrid ne peut-être associée à ma connaissance qu'à un seul dataset de manière active...

Petite précision importante quand même : mes dbGrids sont systématiquement en 'ReadOnly', remplies par un DataSet (zQueryDbGrid) réservé à cet effet; Les Insert, Update, Duplicate, Delete et même SELECT LIMIT1 se font par un autre Dataset (zQuerySUID).

Merci.
Cordialement. Gilles