Discussion :

[FMJ]

Semi-résolu disons --> solution de contournement : le plus utiliser le recordset lié au recordsource du formulaire et les champs liés aux contrôles mais utiliser un nouveau recordset déclaré au niveau du formulaire, laissé ouvert, et dont VBA utilise les enregistrements pour remplir (ou non) les contrôles au gré de la navigation de l'utilisateur.

Bonjour,

J'ai un problème équivalent à celui décrit dans ce thread :
http://www.developpez.net/forums/d15...uete-resultat/

J'ai un formulaire qui se base sur un RecordSource. La requête sous-jacente est calculée dynamiquement en fonction des choix et saisies de l'utilisateur sur des contrôles de filtrage.

Le problème intervient lorsque le choix de l'utilisateur aboutit à une requête sans enregistrement. Dans ce cas, le comportement d'Access consiste à afficher le formulaire complètement vide, sans aucun contrôle. Bref l'utilisateur ne peut plus modifier son choix, est bloqué et ne peut plus que fermer le formulaire.

La solution de contournement consiste à vérifier préalablement que la requête renvoie bien des enregistrements et à alors modifier le RecordSource.

Le problème est que la requête sous-jacente est déjà très lourde et que cela m'emm... de devoir la faire tourner une seconde fois pour pas grand chose.

Une autre solution consiste à ne plus passer par un RecordSource mais à peupler directement chaque champ. En fait, j'ai testé comparativement. Avec le RecordSource, l'affichage du 1er enregistrement est plus long du fait de l'exécution de la requête "complète" mais ensuite la navigation entre enregistrement est beaucoup plus fluide. Or le mode d'utilisation de l'appli correspond à peu d'actions de filtrage pour beaucoup d'actions de navigation. Donc c'est la solution avec la RecordSource qui est la plus efficace.

Connaîtriez-vous une autre solution à ce problème ?

Merci d'avance.

[LedZeppII]

Bonsoir,

Le problème intervient lorsque le choix de l'utilisateur aboutit à une requête sans enregistrement. Dans ce cas, le comportement d'Access consiste à afficher le formulaire complètement vide, sans aucun contrôle. Bref l'utilisateur ne peut plus modifier son choix, est bloqué et ne peut plus que fermer le formulaire.

Et si tu déplaces les contrôles par l'intermédiaire desquels l'utilisateur fait ses choix, de la zone détail vers la zone en-tête de formulaire ?

A+

[FMJ]

Salut

D'une part, du point de vue design du formulaire, cela ne me conviendra pas bien (il s'agit d'un formulaire d'achat extrêmement condensé) et d'autre part je pense pas que cela ai un impact sur la problème.

Les contrôles de filtrage sont totalement décorrélés des champs du recordset du formulaire. Ils ne servent qu'à construire la chaîne de caractères correspondant au recordsource du formulaire.


Autrement j'ai eu une autre idée.

1. Enregistrement de la chaîne courante du recordset (avant le filtrage) dans un controle caché
2. A partir des choix de l'utilisateur, construction de la chaîne du recordset
3. Application de la nouvelle chaîne du record
4. Si Me.recordcount=0, réapplication de l'ancienne chaîne avec un message d'avertissement "Aucun enregistrement"
Mais je sais pas si réexécuter une fois le premier recordset coûtera moins de temps et de ressources que d'exécuter sous VBA un nouveau recordset correspondant au nouveau filtrage, recordset qui sera vide ???


Autrement, si je pouvais avoir directement accès en DAO ou ADO au recordset créé par la chaîne du recordsource, au lieu de lier les contrôles aux champs du recordset, j'appliquerais moi-même les valeurs aux contrôles, lorsque le recordset n'est pas vide. Mais je me suis jamais pencher sur cette question.


Enfin, ça m'étonne que ce cas de figure ne soit pas prévu. Je pense qu'il existe une option pour gérer ce problème et que je me prends la tête pour pas grand chose !

[FMJ]

Bon, j'ai pas trouvé de réelle solution à cette question.

J'ai donc fini par déclarer un recordset au niveau du formulaire qui charge les enregistrements à l'application d'un filtrage et qui reste ouvert toute la session. L'utilisateur le parcourt donc lorsqu'il passe d'un enregistrement à l'autre.

Cela revient à ce qui se passe lorsqu'on déclare un recordsource au niveau du formulaire, sauf qu'au lieu de lier les contrôles avec les champs, c'est le code qui leur affecte une valeur .... si celle-ci n'est pas nulle. Et donc si le filtrage ne renvoie aucun enregistrement, le formulaire n'est pas globalement vide (seuls les contrôles sont nuls).