probleme de rapidité de recherche

Question

Bonjour 

je travail sur une application qui utilise la base de données  access97
j'ai une table "journal" qui a 500 000 enregistrement s
pour afficher le contenue de la table dans un DBGrid  j'ai relie le DBGrid avec Data1 et j'ecris dans le code 

data1.recordsource="select * from journal"
data1.refresh    " et la j'ai un serieu probleme de rapidité il me faux a peu pré  60seconds pour voir les resultats et c'est trop"

est ce que il y'a une methode de recherche plus rapide .

merci d'avance 

HB

cs_DARKSIDIOUS · Answer

Salut,

DBGrid ?? C'est un contrôle VB6 cà ? Ne serait-ce pas l'ancien contrôle DataGrid de VB5 ?

Quel est l'intérêt d'afficher 500 000 enregistrements dans une grille ??? Tu devrais plutôt proposer à l'utilisateur de saisir un filtre avant de charger la liste des données, ce serait plus pratique à utiliser, et plus rapide à exécuter !
______________________________________
DarK Sidious

hbvb6 · Answer

Salut 
merci pour la repense 

mais le probleme n'est  pas dans le DBGrid je peux utiliser un autre controle..!! ,

le probleme est dans la requete,  meme si j'utilise un fitrage entre une date et une autre le probleme reste le meme 

exple 
data1.recorsource="select * from journal where date_action =Date "
data1.refresh  "le probleme reste le même "

je ne sais quoi faire

cs_Exploreur · Answer

Salut,


A defaut quand je charge une listwiev(c'est un exemple) avec X records, je la passe a Visible =False, essaye de faire la même chose avec ton DataGrid, tu gagnes du temps en insertion de donnees...


Ps : Excusez ñoi pour les fautes, lol, je n'aie pas l'habitude d'un clavier qwerty et espagnol...

DarkSidious >> Salut, cela fait un petit momemt que l'on ne te vois plus trop sur le forum 


A+
Exploreur

 Linux a un noyau, Windows un pépin

hbvb6 · Answer

Salut 

merci pour la repense

mais j'ai dis que j'ai pas un probleme de composant ou de chargement de composant le probleme est dans la requete . meme si par exemple je veux savoir le nombre d'enregistrement , avec ce nombre d'enregistrements il y'a toujours le probleme de rapidité

merci 
HB

cs_DARKSIDIOUS · Answer

Salut,

Exploreur >> On me voit plus trop sur VBFrance à cause des boulets qui traînent par ici et qui posent des questions qui n'ont rien à voir avec VB, ou qui postent dans les mauvais forums, ou qui posent des questions qui ont déjà été posées 40 000 fois avant, etc.
De plus, je fais plus vraiment de VB maintenant : Java powaa !!!! Quel plaisir de faire du Java comparé à VB !  Plus rien à voir !
Puis il me tarde de voir le prochain VB... est-ce que microsoft osera une fois de plus sortir un VB totalement incompatble avec VB.NET 3 comme ils ont l'habitude de faire  Je me marrerais bien 

hbvb6 : si tu fais une requête avec un critère, ca devrait normalement être bien plus rapide (puisque beaucoup moins de données à lire/afficher). Essaye de changer de contrôle : passe au Datagrid plutôt (plus récent, bien que datant de 1998 !!!). Idem pour le contrôle Data, utilise plutôt le ADODC qui est plus d'actualité (bien que lui aussi datant de 1998 et oublié depuis des lustres de microsoft !).

Le principe du datagrid étant de n'afficher que ce qui a besoin d'être affiché, l'astuce de notre ami exploreur n'est pas valable : qu'il y ai 100 000 enregistrements ou 10, il devrait mettre autant de temps pour l'affichage (c'est ce qui le rend aussi rapide comparé au ListView !).
______________________________________
DarK Sidious

cs_DARKSIDIOUS · Answer

Salut,

Autre chose au passage : Access, c'est bien, mais c'est fait pour des petites bases de données ! Dès que tu dépasses les 100 000 enregistrements dans une table, il est complètement largué niveau rapidité (et tu en as ici la preuve).

Est-ce que ta table possède des champs de longueur importante (style des champs de type Mémo, qui sont plus lents à lire que les champs de type texte), est-ce que tes tables sont indéxées ?

De plus, quel est l'intérêt de faire un SELECT * sur autant d'enregistrements ? Essaye de n'extraire que les champs qui te sont vraiment utiles, tu y gagnera pas mal en rapidité !

Peut-être devrais-tu aussi envisager d'utiliser un autre système de BD... qui ne se base pas sur un seul fichier...

______________________________________
DarK Sidious

cs_Exploreur · Answer

DarkSidious >> Tu nous fait la crise de la quarantaine...lol...

Desole...DarkSidious...mais quand je mets ma ListView en visible = False, je gagne du temps..certes pas enorme, mais suffisant pour moi...

A+
Exploreur

 Linux a un noyau, Windows un pépin

cs_DARKSIDIOUS · Answer

Salut,

Lol, non je suis un peu comme f0xi : marre de répéter toujours les mêmes choses : en 3 ans, ca use ! 

Concernant ton astuce, elle marche très bien pour le listview, car tu ajoute les éléments un par un, et cela provoque un refresh à chaque ajout, mais le Datagrid (et je pense que le DBGrid fait la même chose) lui se contente de faire un refresh uniquement des éléments affichés, d'où la différence flagrante de performances entre ces deux contrôles !
______________________________________
DarK Sidious

hbvb6 · Answer

salut 
en effet je fait la migration en SQL server , mais en attendant il faut que je regle ce probleme de rapidité

cs_Jack · Answer

Salut
Mon petit grain de sel
** salut Dark, en passant **
Tout dépend de ce que tu vas faire des valeurs recueillies :
- Si tu dois les afficher pour les visualiser, oui, c'est une solution.
- Si tu ne dois récupérer que le nombre d'enregistrements ou ne traiter qu'un faible nombre de résultats d'une requète, passe plutôt à ADODB.
C'est la même chose que ADODC sauf que les composants ne reposent pas sur des objets graphiques, mais uniquement des RecordSet, sortes de tableaus de variables.
Si tu dois les afficher, c'est à toi de programmer la lecture du RecordSet pour insérer les données dans une ListView ou une FlexGrid.
Des exemples existent dans tous les codes qui utilisent des RecordSet.

Avec ADODB, je fais aussi des requètes sur des bases de données en Access 97 et sous Windows NT sur des tromblons qui tournent à 500 MHz (ne rigolez pas) et ça tourne très bien (3 ou 4 secondes pour retrouver une dizaine d'enregistrements parmi 45000)

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

<hr />Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)

hbvb6 · Answer

salut 
merci jack pour la repense 
je vais utiliser ADODB avec access 97  pour tester la rapidité 

A+
HB

cs_DARKSIDIOUS · Answer

Salut,

Jack (salut ;) >> Pour une table contenant 45 000 enregistrements, ca va encore niveau rapidité, mais je crains que pour une table de 500 000 enregistrements, ADODB ou pas, c'est access qui bridera les perfs !

Je le répète : ce genre de problème ne m'étonne pas vraiment sachant que c'est access qui sert de base de données (je me base sur mon expérience personnelle) : Access est pratique, c'est certains, mais pour de petites bases de données avec des tables n'excédant pas les 100 000 enregistrements, au delà, il faut vraiment songer à passer à un SGBD plus robuste et rapide !

Un petit lien au passage : http://loufab.developpez.com/optimisation/
______________________________________
DarK Sidious

cs_DARKSIDIOUS · Answer

Salut,

Et puis pour appuyer mes dires (apparement, j'suis pas le seul à penser cà :p)

http://fadace.developpez.com/sgbdcmp
______________________________________
DarK Sidious

hbvb6 · Answer

salut ;


j'ai fait un petit exemple pour tester ADO malgré que je pense que c'est la meme chose , 4 second pour 45000 eng =20 second pour 225 000 enrg !!??

j'ai trouver des dificulté pour connecter ma base access97 avec ado et aussi pour afficher les resultats dans un grid, j'ai meme pas trouver le bon composant 

je suis perdu

cs_DARKSIDIOUS · Answer

Salut,

Si tu lisais au moins ce que je disais... DataGrid et contrôle ADODC pour utiliser ADO et afficher dans une grille.

Concernant les performances : c'est normal : access n'est pas fait pour autant de données !
______________________________________
DarK Sidious

PCPT · Answer

salut,

en effet un BD access avec autant de données, c'est voué à l'échec!
as-tu essayé ta requête dans access ? pour comparer....

un autre point tout bête mais très efficace pour lister tous les champs plus rapidement : NE PAS METTRE *

ACCESS
data1.RecordSource= "SELECT journal.champs1, journal.champs2, journal.date_action " & _
                    "FROM journal " & _
                    "WHERE journal.date_action = #" & Date & "# " & _
                    "TOP 200;"

SQLSERVER
data1.RecordSource= "SELECT [journal.champs1], [journal.champs2], [journal.date_action] " & _

                    "FROM journal " & _

                    "WHERE [journal.date_action] = #" & Date & "# " & _
                    "LIMIT 200;"

++
<hr size="2" width="100%" />Prenez un instant pour répondre à [infomsg_SONDAGE-POP3-POUR-CS_769706.aspx ce sondage] svp

hbvb6 · Answer

salut 

merci pour cette solution mais je vais la essayer comme même 

et j'ai pas essayé ma requete dans access

merci 

A+

HB

PCPT · Answer

par contre petite erreur de ma part...

sous SQLSERVER, remplace mes []  par des `
(attention pas des ')
les crochets c'est pour access

tout çà n'est indispensable que pour les noms de champs/tables comprenant des espaces...
<hr size="2" width="100%" />Prenez un instant pour répondre à [infomsg_SONDAGE-POP3-POUR-CS_769706.aspx ce sondage] svp

hbvb6 · Answer

salut 


et en vb6 j'ai essayé 


data1.recordsource="select * from journal where ......  top 200;"


data1.refresh  "il y a une erreur ,  la requete est fause ,oui?

PCPT · Answer

copie pas la moitié de ce que j'indique aussi....

* à virer, c'est pas fait...

et çà fonctionne sans le TOP? (dans access...)

Probleme de rapidité de recherche

23 réponses

Votre réponse

Discussions similaires