Probleme de rapidité de recherche

Signaler
Messages postés
40
Date d'inscription
mardi 29 janvier 2008
Statut
Membre
Dernière intervention
3 juin 2009
-
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
-
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

23 réponses

Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
125
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
Messages postés
40
Date d'inscription
mardi 29 janvier 2008
Statut
Membre
Dernière intervention
3 juin 2009

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
Messages postés
4822
Date d'inscription
lundi 11 novembre 2002
Statut
Membre
Dernière intervention
15 novembre 2016
14
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
Messages postés
40
Date d'inscription
mardi 29 janvier 2008
Statut
Membre
Dernière intervention
3 juin 2009

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
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
125
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
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
125
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
Messages postés
4822
Date d'inscription
lundi 11 novembre 2002
Statut
Membre
Dernière intervention
15 novembre 2016
14
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
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
125
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
Messages postés
40
Date d'inscription
mardi 29 janvier 2008
Statut
Membre
Dernière intervention
3 juin 2009

salut
en effet je fait la migration en SQL server , mais en attendant il faut que je regle ce probleme de rapidité
Messages postés
14008
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
76
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)
Messages postés
40
Date d'inscription
mardi 29 janvier 2008
Statut
Membre
Dernière intervention
3 juin 2009

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

A+
HB
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
125
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
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
125
Salut,

Et puis pour appuyer mes dires (apparement, j'suis pas le seul à penser cà :p)

http://fadace.developpez.com/sgbdcmp
______________________________________
DarK Sidious
Messages postés
40
Date d'inscription
mardi 29 janvier 2008
Statut
Membre
Dernière intervention
3 juin 2009

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
Messages postés
15814
Date d'inscription
jeudi 8 août 2002
Statut
Modérateur
Dernière intervention
4 mars 2013
125
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
Messages postés
13280
Date d'inscription
lundi 13 décembre 2004
Statut
Modérateur
Dernière intervention
3 février 2018
46
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
Messages postés
40
Date d'inscription
mardi 29 janvier 2008
Statut
Membre
Dernière intervention
3 juin 2009

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
Messages postés
13280
Date d'inscription
lundi 13 décembre 2004
Statut
Modérateur
Dernière intervention
3 février 2018
46
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
Messages postés
40
Date d'inscription
mardi 29 janvier 2008
Statut
Membre
Dernière intervention
3 juin 2009

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?
Messages postés
13280
Date d'inscription
lundi 13 décembre 2004
Statut
Modérateur
Dernière intervention
3 février 2018
46
copie pas la moitié de ce que j'indique aussi....

* à virer, c'est pas fait...

et çà fonctionne sans le TOP? (dans access...)