Discussion :

[Filou07]

Bonjour à tous,

J'ai un formulaire costaud qui charge une table très lourde et sur un réseau distant. Je souhaiterais accélérer le délai d'ouverture et de passage d'un enregistrement à un autre.

Quelle est la meilleure solution en vba : changer le recordsource (pour passer d'un enregistrement à un autre ça va être la galère) ou filtrer le formulaire ?

Merci pour vos avis éclairés

[Didier L]

Le soucis c'est que le moteur Jet d'Access n'est pas "client / serveur" donc il rapatrie toutes les données avant de les filtrer.
Essaye de mettre un filtre en ne sélection que le premier ID pour voir si ton formulaire s'ouvre plus vite, mais je n'en suis pas sur
Si cela marche, on pourra ensuite programmer des bouton de navigation pour passer au suivant ou au précédent.
Mais le premier test à faire est bien sur l'ouverture.
Maintenant as tu dans ce formulaire plusieurs sous formulaire ?
As tu des onglets ?
Car Access charge aussi tous ces sous formulaire.
J'ai eu le cas ou j'ai été obligé de mettre mes sous formulaire "indépendant" sans source, et a chaque fois que j'arrivait sur un nouvel onglet, alors je chargeait mon sous formulaire.
Ce n'était pas la peine de tout charger alors que l'utilisateur risquait de ne pas aller sur tel ou tel onglet
Il y a peut-être des astuce, mais il faut déjà analyser le formulaire et savoir pourquoi il est lourd.
Parfois ce peut-être aussi a cause d'une requête source mal construite ou pas optimisé, etc ...

[alassanediakite]

Salut
Didier
J'ajouterai seulement que JET est remplacé par ACE dépuis la version 2007.
@+

[Invité]

Bonjour

A cela, je rajouterais quelques informations extraites d'un tuto de Loufab : http://loufab.developpez.com/tutorie...sation/#LIII-F

Philippe

[Filou07]

Bonjour,

Merci pour vos réponses

@Philippe JOCHMANS : j'ai appris pas mal de choses sur le tuto et moi qui suis un adepte du dlookup, il va falloir que je me calme

Sinon en effet j'ai un gros formulaire avec des onglets, des listes déroulantes et treeview. Pour le treeview, qui se trouve dans un onglet, je fais comme toi en ne le calculant que lorsque l'utilisateur arrive sur l'onglet.

L'ouverture sur filtrage ne change rien en termes de performance. Je vais partir sur la modification du rowsource avec une condition WHERE pour n'afficher qu'un seul enregistrement.

Mais comment faire pour que mes boutons "Suivant" et "Précédent" fonctionnent correctement ?

Je ne peux pas simplement faire un "SELECT.... WHERE ID=" & me.ID+1 car si des enregistrements ont été supprimés, il y a un "trou" et ça ne fonctionnerait plus

[loufab]

Bonjour,

En effet le problème de trou dans le numéroAuto sont pénibles.

Mais tu peux récupérer les records 2 par 2.

Exemple :

Code :

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

1
2
3
4
5
 
SELECT TOP 2 ttable.*
FROM ttable
WHERE ttable.id)>7
ORDER BY ttable.id;

En contrôlant la valeur de ton id, ici j'ai mis 7 en dur, tu as toujours un record d'avance connu, donc imaginer ne faire changer ta source qu'une fois sur 2, fini les risques de trous. Reste à imaginer comment tu vas gérer la fin et le début, mais cela n'a rien de bien complexe.

Cordialement,

[marot_r]

Pour trouver le prochain enregistrement (dans l'ordre des clefs)

Code :

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

=DMin("Id","TaTable","Id>" & Me.Id)

Je n'ai aucune idée du temps de calcul que cela implique.

Une idée, pour éviter cela :
Créer un formulaire qui présente la liste des fiches disponibles.
Ouvrir le formulaire qui affiche une et une seule fiche choisie.

Le chargement des listes déroulantes peut être TRÈS lourds. On peut tricher en ne les chargeant qu'à réception du focus. Pour que cela ne se voit pas, la donnée est affichée dans un textbox "glissé" sous la combobox.

A+

[alassanediakite]

Salut
Est-ce possible de créer une requête SQL DIRECT vers la source distante (avec filtre et juste les champs nécessaires).
Si oui, cela pourra réduire le temps...

• un premier formulaire de choix: zone de critère puis modification et lancement d'un premier SQL DIRECT par VBA
• changement d'un second SQL DIRECT par VBA en fonction du choix puis ouverture du second formulaire

Il est possible de mettre les fonctionnalités du premier formulaire directement dans le second.
@+

[Filou07]

Bonjour,

Merci à vous tous, si si, le coup des enregistrements 2 par 2 est vraiment futé ! Je crois même que je vais faire plus vicieux en passant à 3 et en rechargeant à chaque fois : dans les 3 il y aura le précédent, le en-cours et le suivant. Si la requête n'en retourne que 2 c'est que je suis proche du début ou de la fin de la table.

En ce qui concerne la liste déroulante de recherche elle est dans l'entête du formulaire et donc n'est chargée qu'une seule fois. Si j'observe un ralentissement quand la base sera en production, je la calculerai à réception du focus.

Merci encore, je ferai un petit récap quand j'aurai fini

[loufab]

Tu peux essayer d'utiliser une variable de paramétrage pour le TOP.

Exemple :

Code :

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

SELECT TOP fnbrRecord() ... FROM

et

Code :

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

1
2
3
4
5
public function fnbrRecord() as long
 
fnbrRecord=3
 
End function

A tester étant donné que cette clause est analysée avant que la requête soit jouée par le moteur, il est possible que ça ne fonctionne pas.
Dans ce cas, une définition de la source à la volée est toujours possible avec un Querydefs()

Cordialement,