Discussion :

[Mairequimby]

Bonjour,

J'ai attentivement lu le document suivante sur le DAO
http://warin.developpez.com/access/dao/

J'ai créer un fichier qui ressemble à l'exemple au point 5.5.2 sur les blocs. La méthode est super mais voila ma question. On dit toujours qu'un Recordset doit être fermé après son utilisation. Or comment faire fonctionner ce fichier si le Recorset est toujours ouvert afin de récupérer la valeur pour passer aux enregistrements suivants. Est-ce qu'une solution est de créer une variable dont l'existence est possible en dehors de la procédure?

Je sais que fermé un Recorset est plus propre, mais qu'elle est l'impact réelle de le laisser ouvert outre la propreté.

Merci beaucoup.

[marot_r]

Bonjour.

Je ne suis pas sur de comprendre ta question.
Si tu ne fermes pas explicitement un recordset dans une procédure il reste ouvert jusqu'à ce que tu sortes de la procédure.
Après le compliateur le ferme pour toi. C'est se qu'on appelle la portée d'une variable. Elle est "fonctionnelle" et définie à son niveau et généralement pour tous les niveaux subséquents mais dés qu'on quitte le niveau elle est "libérée" et devient indéfinie.
Le faire soi-même est en effet plus propre car cela libère la mémoire associée dés ce momnet (enfin cela signale au compilateur qu'il peut le faire) et éventuellement les enregistrements verrouillés (ça c'est immédiat).

L'autre avantage est que cela indique à l'humain qui lit ton code que tu en as fini avec cet objet.
Avec la vitesse d'éxécution des machines moderne, optimiser pour l'humain est ce qu'il faut faire.
On ne peut pas le remplacer par une version 2 fois plus puissante tous les 18 mois.

A+

[Mairequimby]

Merci pour ta réponse,

Ok je comprend la porté du recordset, mais si tu télécharge le fichier Access de l'exemple 5.5.2 de mon post précédent http://warin.developpez.com/access/d...=partie_5#L5.5 , les recordset ne sont pas fermé dans cet exemple pour y recourir ensuite. Si je les fermes à la fin du code, les bouton précédent et suivant ne fonctionne plus. Le recordset demeure donc ouvert tout le temps que le formulaire est ouvert. Je ne trouve pas ça pratique si c'est ton formulaire principale et qui est tout le temps ouvert. La solution pour fermé le recorset entre deux appel est de stocker une variable dans une textbox du formulaire pour les appels suivants (afin d'indiquer la position du curseur dans le getrows).

est-ce que ma solution est bonne ou je devrais faire autrement?

[marot_r]

Bonjour.

En fait tant que ton formulaire est ouvert, c'est que tu manipules les données associées et donc il est logique de garder le recordset ouvert.
De plus, ouvrir et fermer un recordset (sans compter retrouver ta position) est "coûteux" en temps d'éxécution.

Bon personnellement je ne faits sert jamais de cela pour mes formulaires.
Je fais des formulaire liés et Access se charge de gérer les détails.

A+

[Mairequimby]

Super, je suis donc sur la bonne voie.

Je croyais que de faire des formulaires et sous-formulaire sur des requêtes étaient plus problématique lors du déploiement de l'application en Frontale-Dorsale en mode Multi-utilisateur. Il ne vaut pas mieux utiliser des recordset?

[marot_r]

Pas vraiment.

De toute façon en interne Access utilise des recordsets.
Donc là tu t'embêtes à refaire ce que les ingénieurs de M$ ont mis au point depuis des années.
Ce peut-être un bon exercice mais je n'y vois pas d'intérêt en dehors de cela.

Le seul avantage d'utiliser des recordsets est si tu veux dépasser les 5 utilisateurs en lecture/écriture simultanément.
Et là apparement qu'il vaut mieux utiliser la bibliothèque ADO qui permet des recordsets déconnectés.
J'ai eu connaissance d'une appli qui permet d'avoir 200 utilisateurs mais qui travaille chacun sur leur enregistrement.
D'après ce que je sais elle n'ouvre la connexion que le temps de mettre à jour cet enregistrement.
Mais c'est un cas particulier ou l'utilisateur se focalise juste sur un dossier.

A+