Bonjour,
je commence à attendre l'ordinateur surtout sur un formulaire assez chargé
basé sur une requette assez grande. Alors, Question de principe, qu'est ce
qui est mieu d'utiliser des rechdom pour afficher des champs ou bien
rajouter ces champs dans la requette? En fait c'est pour savoir si j'élimine
des champs de ma requette et d'utiliser les rechdom pour les afficher.
Par ailleur, où puis je trouver qlq règles de base à respecter pour que la
base reste rapide.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Anor
Bonjour news,
Les fonctions de domaine rechdom sont très lentes. A n'utiliser qu'occasionnellement pour afficher une valeur par si, et effectuer un contrôle par là.
- Essayer d'optimiser ou simplifier la requête source du formulaire .... (des fois, on fait ne fait pas forcément simple ...)
- indexer les champs utilisés dans les conditions WHERE ne pas indexer trop de champs non plus ...
Voilà et pour terminer, un peu de lecture : http://access.seneque.free.fr/optimisation.htm -- à+ Arnaud ------------------------------------------- Conseils d'utilisation, sites recommandés : http://users.skynet.be/mpfa/ petit à petit, www.anor.fr.st fait son nid -------------------------------------------
| Bonjour, | je commence à attendre l'ordinateur surtout sur un formulaire assez | chargé basé sur une requette assez grande. Alors, Question de | principe, qu'est ce qui est mieu d'utiliser des rechdom pour afficher | des champs ou bien rajouter ces champs dans la requette? En fait | c'est pour savoir si j'élimine des champs de ma requette et | d'utiliser les rechdom pour les afficher. | | Par ailleur, où puis je trouver qlq règles de base à respecter pour | que la base reste rapide. | | Merci d'avance | ely
Bonjour news,
Les fonctions de domaine rechdom sont très lentes.
A n'utiliser qu'occasionnellement pour afficher une valeur par si,
et effectuer un contrôle par là.
- Essayer d'optimiser ou simplifier la requête source du formulaire ....
(des fois, on fait ne fait pas forcément simple ...)
- indexer les champs utilisés dans les conditions WHERE
ne pas indexer trop de champs non plus ...
Voilà et pour terminer, un peu de lecture :
http://access.seneque.free.fr/optimisation.htm
--
à+
Arnaud
-------------------------------------------
Conseils d'utilisation, sites recommandés :
http://users.skynet.be/mpfa/
petit à petit, www.anor.fr.st fait son nid
-------------------------------------------
| Bonjour,
| je commence à attendre l'ordinateur surtout sur un formulaire assez
| chargé basé sur une requette assez grande. Alors, Question de
| principe, qu'est ce qui est mieu d'utiliser des rechdom pour afficher
| des champs ou bien rajouter ces champs dans la requette? En fait
| c'est pour savoir si j'élimine des champs de ma requette et
| d'utiliser les rechdom pour les afficher.
|
| Par ailleur, où puis je trouver qlq règles de base à respecter pour
| que la base reste rapide.
|
| Merci d'avance
| ely
Les fonctions de domaine rechdom sont très lentes. A n'utiliser qu'occasionnellement pour afficher une valeur par si, et effectuer un contrôle par là.
- Essayer d'optimiser ou simplifier la requête source du formulaire .... (des fois, on fait ne fait pas forcément simple ...)
- indexer les champs utilisés dans les conditions WHERE ne pas indexer trop de champs non plus ...
Voilà et pour terminer, un peu de lecture : http://access.seneque.free.fr/optimisation.htm -- à+ Arnaud ------------------------------------------- Conseils d'utilisation, sites recommandés : http://users.skynet.be/mpfa/ petit à petit, www.anor.fr.st fait son nid -------------------------------------------
| Bonjour, | je commence à attendre l'ordinateur surtout sur un formulaire assez | chargé basé sur une requette assez grande. Alors, Question de | principe, qu'est ce qui est mieu d'utiliser des rechdom pour afficher | des champs ou bien rajouter ces champs dans la requette? En fait | c'est pour savoir si j'élimine des champs de ma requette et | d'utiliser les rechdom pour les afficher. | | Par ailleur, où puis je trouver qlq règles de base à respecter pour | que la base reste rapide. | | Merci d'avance | ely
news
Bonjour, Merci à tous informations notées. J'ai 2 autres questions svp: -il vaut mieux faire des formulaires sur des tables ou sur des requettes? de point de vue rapidité? -est ce que si on définit qlq champs ds une table, comme une liste déroulante d'autres tables ralentie le traitement après? car c'est pratique mais est ce que on le paie après? Tiens une dernière question, il vaut mieu faire une grande requette qui sera utilisé par plusieurs formulaires et états ou bien faire plusieures requettes? je pense que plusieures c'est plus rapide mais ça prend plus de travail!c'est correct? merci d'avance ely
"Philippe PONS" a écrit dans le message de news:3f127d81$0$10867$
Ton analyse est bonne: ce qui prend du temps c'est le chargement des données. Si les données résident sur un autre ordinateur et que le réseau est lent, la situation est aggravée. Une solution consiste donc à ne charger que les données nécessaires. Par exemple, si un formulaire est basée sur une table client, c'est alors un
formulaire dépendant d'une source de données. On peut le rendre indépendant en supprimant la référence à la table CLIENT dans la source du formulaire. Ensuite installer sur le form une liste déroulante modifiable qui affiche le
nom des clients. Quand l'utilisateur sélectionne un nom de client, une requête SQL ramène uniquement les données concernant ce client. Seule l'information utile transite par le réseau. Il faut ensuite afficher les données dans les champs texte. En cas de modification, il faut une requête SQL pour mettre à jour l'enregsitrement corespondant. Bien sur, avec les formulaires indépendants, il y a plus de programmation, mais c'est plus rapide. Cordialement Philipe.
"news" a écrit dans le message de news: 3f127863$0$26599$
Bonjour, je commence à attendre l'ordinateur surtout sur un formulaire assez chargé
basé sur une requette assez grande. Alors, Question de principe, qu'est ce
qui est mieu d'utiliser des rechdom pour afficher des champs ou bien rajouter ces champs dans la requette? En fait c'est pour savoir si j'élimine
des champs de ma requette et d'utiliser les rechdom pour les afficher.
Par ailleur, où puis je trouver qlq règles de base à respecter pour que la
base reste rapide.
Merci d'avance ely
Bonjour,
Merci à tous informations notées. J'ai 2 autres questions svp:
-il vaut mieux faire des formulaires sur des tables ou sur des requettes? de
point de vue rapidité?
-est ce que si on définit qlq champs ds une table, comme une liste
déroulante d'autres tables ralentie le traitement après? car c'est pratique
mais est ce que on le paie après?
Tiens une dernière question, il vaut mieu faire une grande requette qui sera
utilisé par plusieurs formulaires et états ou bien faire plusieures
requettes?
je pense que plusieures c'est plus rapide mais ça prend plus de
travail!c'est correct?
merci d'avance
ely
"Philippe PONS" <phpons@free.fr> a écrit dans le message de
news:3f127d81$0$10867$626a54ce@news.free.fr...
Ton analyse est bonne: ce qui prend du temps c'est le chargement des
données.
Si les données résident sur un autre ordinateur et que le réseau est lent,
la situation est aggravée.
Une solution consiste donc à ne charger que les données nécessaires.
Par exemple, si un formulaire est basée sur une table client, c'est alors
un
formulaire dépendant d'une source de données.
On peut le rendre indépendant en supprimant la référence à la table CLIENT
dans la source du formulaire.
Ensuite installer sur le form une liste déroulante modifiable qui affiche
le
nom des clients.
Quand l'utilisateur sélectionne un nom de client, une requête SQL ramène
uniquement les données concernant ce client.
Seule l'information utile transite par le réseau.
Il faut ensuite afficher les données dans les champs texte.
En cas de modification, il faut une requête SQL pour mettre à jour
l'enregsitrement corespondant.
Bien sur, avec les formulaires indépendants, il y a plus de programmation,
mais c'est plus rapide.
Cordialement
Philipe.
"news" <ely@free.fr> a écrit dans le message de news:
3f127863$0$26599$626a54ce@news.free.fr...
Bonjour,
je commence à attendre l'ordinateur surtout sur un formulaire assez
chargé
basé sur une requette assez grande. Alors, Question de principe, qu'est
ce
qui est mieu d'utiliser des rechdom pour afficher des champs ou bien
rajouter ces champs dans la requette? En fait c'est pour savoir si
j'élimine
des champs de ma requette et d'utiliser les rechdom pour les afficher.
Par ailleur, où puis je trouver qlq règles de base à respecter pour que
la
Bonjour, Merci à tous informations notées. J'ai 2 autres questions svp: -il vaut mieux faire des formulaires sur des tables ou sur des requettes? de point de vue rapidité? -est ce que si on définit qlq champs ds une table, comme une liste déroulante d'autres tables ralentie le traitement après? car c'est pratique mais est ce que on le paie après? Tiens une dernière question, il vaut mieu faire une grande requette qui sera utilisé par plusieurs formulaires et états ou bien faire plusieures requettes? je pense que plusieures c'est plus rapide mais ça prend plus de travail!c'est correct? merci d'avance ely
"Philippe PONS" a écrit dans le message de news:3f127d81$0$10867$
Ton analyse est bonne: ce qui prend du temps c'est le chargement des données. Si les données résident sur un autre ordinateur et que le réseau est lent, la situation est aggravée. Une solution consiste donc à ne charger que les données nécessaires. Par exemple, si un formulaire est basée sur une table client, c'est alors un
formulaire dépendant d'une source de données. On peut le rendre indépendant en supprimant la référence à la table CLIENT dans la source du formulaire. Ensuite installer sur le form une liste déroulante modifiable qui affiche le
nom des clients. Quand l'utilisateur sélectionne un nom de client, une requête SQL ramène uniquement les données concernant ce client. Seule l'information utile transite par le réseau. Il faut ensuite afficher les données dans les champs texte. En cas de modification, il faut une requête SQL pour mettre à jour l'enregsitrement corespondant. Bien sur, avec les formulaires indépendants, il y a plus de programmation, mais c'est plus rapide. Cordialement Philipe.
"news" a écrit dans le message de news: 3f127863$0$26599$
Bonjour, je commence à attendre l'ordinateur surtout sur un formulaire assez chargé
basé sur une requette assez grande. Alors, Question de principe, qu'est ce
qui est mieu d'utiliser des rechdom pour afficher des champs ou bien rajouter ces champs dans la requette? En fait c'est pour savoir si j'élimine
des champs de ma requette et d'utiliser les rechdom pour les afficher.
Par ailleur, où puis je trouver qlq règles de base à respecter pour que la
base reste rapide.
Merci d'avance ely
Anor
Bonjour,
| Bonjour, | Merci à tous informations notées. J'ai 2 autres questions svp: | -il vaut mieux faire des formulaires sur des tables ou sur des | requettes? de point de vue rapidité?
Perso, je préfère une requête avec seulement les champs nécessaires. En outre, ça permet de ramener les autres champs liés côté 1 de la relation.
De plus, j'aime bien par défaut ne faire interroger que le minimum de données (celles du jour par exemple), quitte à avoir un deuxième formulaire identique servant à la modification par opposition à ce formulaire de saisie.
| -est ce que si on définit qlq champs ds une table, comme une liste | déroulante d'autres tables ralentie le traitement après?
Je suppose effectivement que remplir des zones de liste déroulantes prend un peu de temps.
| car c'est | pratique mais est ce que on le paie après?
Si tu veux vraiment t'amuser à chronométrer, voici une petite fonction :
Public Declare Function GetTime Lib "winmm.dll" _ Alias "timeGetTime" () As Long
Dim StartTime, EndTime As Long
Function Chronometre(START_STOP As String) As Long Select Case START_STOP
Case Is = "START" StartTime = GetTime() Chronometre = 0 Case Is = "STOP" EndTime = GetTime() Chronometre = EndTime - StartTime End Select End Function Exemple d'utilisation
Sub MesureTempsOuverture() Dim i As Long Chronometre ("START") DoCmd.OpenForm "LeFormulaire" msgbox Chronometre("STOP") & " millisecondes" End Sub
Tu nous donneras les résultats, hein ;-))
| Tiens une dernière question, il vaut mieu faire une grande requette | qui sera utilisé par plusieurs formulaires et états ou bien faire | plusieures requettes? | je pense que plusieures c'est plus rapide mais ça prend plus de | travail!c'est correct? | merci d'avance | ely
Je pense qu'une requête sans surplus, c'est mieux. Ainsi, si pour les besoins du formulaire 1 tu mets un champ calculé, tu pourras te passer de ce calcul si pas besoin dans le formulaire 2. ps : personnellement, je n'appelle pas des requêtes depuis mes formulaires, je préfère mettre leur code SQL directement en source du formulaire, mais c'est une sombre histoire de maintenabilité. -- à+ Arnaud ------------------------------------------- Conseils d'utilisation, sites recommandés : http://users.skynet.be/mpfa/ petit à petit, www.anor.fr.st fait son nid -------------------------------------------
Bonjour,
| Bonjour,
| Merci à tous informations notées. J'ai 2 autres questions svp:
| -il vaut mieux faire des formulaires sur des tables ou sur des
| requettes? de point de vue rapidité?
Perso, je préfère une requête avec seulement les champs nécessaires.
En outre, ça permet de ramener les autres champs liés côté 1 de la relation.
De plus, j'aime bien par défaut ne faire interroger que le minimum de données
(celles du jour par exemple), quitte à avoir un deuxième formulaire identique
servant à la modification par opposition à ce formulaire de saisie.
| -est ce que si on définit qlq champs ds une table, comme une liste
| déroulante d'autres tables ralentie le traitement après?
Je suppose effectivement que remplir des zones de liste déroulantes prend un peu de temps.
| car c'est
| pratique mais est ce que on le paie après?
Si tu veux vraiment t'amuser à chronométrer, voici une petite fonction :
Public Declare Function GetTime Lib "winmm.dll" _
Alias "timeGetTime" () As Long
Dim StartTime, EndTime As Long
Function Chronometre(START_STOP As String) As Long
Select Case START_STOP
Case Is = "START"
StartTime = GetTime()
Chronometre = 0
Case Is = "STOP"
EndTime = GetTime()
Chronometre = EndTime - StartTime
End Select
End Function
Exemple d'utilisation
Sub MesureTempsOuverture()
Dim i As Long
Chronometre ("START")
DoCmd.OpenForm "LeFormulaire"
msgbox Chronometre("STOP") & " millisecondes"
End Sub
Tu nous donneras les résultats, hein ;-))
| Tiens une dernière question, il vaut mieu faire une grande requette
| qui sera utilisé par plusieurs formulaires et états ou bien faire
| plusieures requettes?
| je pense que plusieures c'est plus rapide mais ça prend plus de
| travail!c'est correct?
| merci d'avance
| ely
Je pense qu'une requête sans surplus, c'est mieux.
Ainsi, si pour les besoins du formulaire 1 tu mets un
champ calculé, tu pourras te passer de ce calcul si pas besoin dans le formulaire 2.
ps : personnellement, je n'appelle pas des requêtes depuis mes formulaires,
je préfère mettre leur code SQL directement en source du formulaire,
mais c'est une sombre histoire de maintenabilité.
--
à+
Arnaud
-------------------------------------------
Conseils d'utilisation, sites recommandés :
http://users.skynet.be/mpfa/
petit à petit, www.anor.fr.st fait son nid
-------------------------------------------
| Bonjour, | Merci à tous informations notées. J'ai 2 autres questions svp: | -il vaut mieux faire des formulaires sur des tables ou sur des | requettes? de point de vue rapidité?
Perso, je préfère une requête avec seulement les champs nécessaires. En outre, ça permet de ramener les autres champs liés côté 1 de la relation.
De plus, j'aime bien par défaut ne faire interroger que le minimum de données (celles du jour par exemple), quitte à avoir un deuxième formulaire identique servant à la modification par opposition à ce formulaire de saisie.
| -est ce que si on définit qlq champs ds une table, comme une liste | déroulante d'autres tables ralentie le traitement après?
Je suppose effectivement que remplir des zones de liste déroulantes prend un peu de temps.
| car c'est | pratique mais est ce que on le paie après?
Si tu veux vraiment t'amuser à chronométrer, voici une petite fonction :
Public Declare Function GetTime Lib "winmm.dll" _ Alias "timeGetTime" () As Long
Dim StartTime, EndTime As Long
Function Chronometre(START_STOP As String) As Long Select Case START_STOP
Case Is = "START" StartTime = GetTime() Chronometre = 0 Case Is = "STOP" EndTime = GetTime() Chronometre = EndTime - StartTime End Select End Function Exemple d'utilisation
Sub MesureTempsOuverture() Dim i As Long Chronometre ("START") DoCmd.OpenForm "LeFormulaire" msgbox Chronometre("STOP") & " millisecondes" End Sub
Tu nous donneras les résultats, hein ;-))
| Tiens une dernière question, il vaut mieu faire une grande requette | qui sera utilisé par plusieurs formulaires et états ou bien faire | plusieures requettes? | je pense que plusieures c'est plus rapide mais ça prend plus de | travail!c'est correct? | merci d'avance | ely
Je pense qu'une requête sans surplus, c'est mieux. Ainsi, si pour les besoins du formulaire 1 tu mets un champ calculé, tu pourras te passer de ce calcul si pas besoin dans le formulaire 2. ps : personnellement, je n'appelle pas des requêtes depuis mes formulaires, je préfère mettre leur code SQL directement en source du formulaire, mais c'est une sombre histoire de maintenabilité. -- à+ Arnaud ------------------------------------------- Conseils d'utilisation, sites recommandés : http://users.skynet.be/mpfa/ petit à petit, www.anor.fr.st fait son nid -------------------------------------------
Raymond
RE.
-est ce que si on définit qlq champs ds une table, comme une liste déroulante d'autres tables ralentie le traitement après? car c'est pratique mais est ce que on le paie après?
Si la propriété 'autoétendre' est à oui, c'est formidable, et pénalisant au maximum dans un formulaire. A chaque requery, toute la liste est rechargée à partir du serveur et s'il en existe une dizaine sur des tables de 10000 enr, ça pénalise vraiment.
-- @+ Raymond Access MVP. http://access.seneque.free.fr/ http://users.skynet.be/mpfa/charte.htm pour une meilleure efficacité de tes interventions sur MPFA.
"Anor" a écrit dans le message de news:
RE.
-est ce que si on définit qlq champs ds une table, comme une liste
déroulante d'autres tables ralentie le traitement après? car c'est pratique
mais est ce que on le paie après?
Si la propriété 'autoétendre' est à oui, c'est formidable, et pénalisant au
maximum dans un formulaire. A chaque requery, toute la liste est rechargée à
partir du serveur et s'il en existe une dizaine sur des tables de 10000 enr,
ça pénalise vraiment.
--
@+
Raymond Access MVP.
http://access.seneque.free.fr/
http://users.skynet.be/mpfa/charte.htm pour une meilleure
efficacité de tes interventions sur MPFA.
"Anor" <nospam_news@anor.fr.st> a écrit dans le message de
news:ugu6xlgSDHA.2248@TK2MSFTNGP11.phx.gbl...
-est ce que si on définit qlq champs ds une table, comme une liste déroulante d'autres tables ralentie le traitement après? car c'est pratique mais est ce que on le paie après?
Si la propriété 'autoétendre' est à oui, c'est formidable, et pénalisant au maximum dans un formulaire. A chaque requery, toute la liste est rechargée à partir du serveur et s'il en existe une dizaine sur des tables de 10000 enr, ça pénalise vraiment.
-- @+ Raymond Access MVP. http://access.seneque.free.fr/ http://users.skynet.be/mpfa/charte.htm pour une meilleure efficacité de tes interventions sur MPFA.
