code VBA versus assistant Access

Version imprimable

08/04/2006, 02h23
zephyr59

code VBA versus assistant Access

Bonjour,

Ayant des connaissances en sql et l'assistant d'access étant assez facile à exploiter, je n'ai pas eu trop de soucis pour déveloper ma 1er appli.

A présent, je souhaite pouvoir exploiter davantage les possibilités d'access en utilisant notamment les recordset. Dans le faq, j'ai trouvé effectivement bon nombres d'infos sur leur utilisation. Mais finalement, peu sur leur intégration. Je m'explique :

Pour la mise en oeuvre d'un formulaire :

avec l'assistant Access

1) rattachement de la requête au formulaire
2) rattachement des champs de la requête aux controles du formulaire

Se fait de manière simple puisqu'il s'agit plus de "paramétrage de zones prédéfinies". Avec en plus gestion automatique de navigation, ajout,suppression et maj de table.

avec le code VBA

1) rattachement de la requete avec le formulaire (cf faq)
2) rattachement du recordset avec la requête (cf faq)
3) rattachement des champs du recordset aux controles du formulaire (cf faq)

mes questions sont les suivantes :

Par analogie avec le mode assistant Access :
- où doit on insérer le code VBA ?
- quand appelle la fonction insérée ?
- la gestion en maj, création et suppression est elle gérée en automatique avec le recordset ou faut il une

Citation:

gestion manuelle

- Si gestion manuelle :
où doit on insérer le code ?
quand appelle-t-on la fonction insérée

Si vous disposez d'un exemple complet je suis preneur ?

[/b]
08/04/2006, 11h27
loufab
Access est un produit organisé autour de l'événementiel, c'est à dire que les actions (code VBA ou macro) sont appelées suite à un événement.

L'événement est pour la plupart du temps déclanché par l'action de l'utilisateur :
- clic sur un bouton
  déplacement d'un enregistrement à un autre
  sortie ou entrée dans un formulaire
Il existe quelques exceptions :
- le Timer, dans ce cas l'événement est déclanché à intervale régulier sans action de l'utilisateur.
  la mise en page ou l'impression d'état ou pendant ce cycle on peut intervenir sur le processus.
  ...
Seuls ces 2 objets (état, formulaire) procurent des événements, donc pas question de compter de déclencher des événements utilisateurs lors de la visualisation de requêtes ou de tables.

Le code VBA est intégré dans 3 objets : Etat, Formulaire, Module
Les procédures et fonctions déclaré dans les états et formulaires ne peuvent être utilisé qu'au sein de ceux-ci. Pas question donc d'appeler une procédure d'un formulaire à partir d'un état.

Dans les modules (suivant leur déclaration Private/Public) une fonction ou procédure pourra être appelée en interne (dans ce module uniquement) ou globalement (dans toute l'application).

Les fonctions (le cas à part) : Lorsqu'elles sont déclarés dans un module et qu'elles sont "Public" on peut les appeler dans les formulaires et état (dans les modules ou certaines propriétés de certains contrôles) mais également dans les requêtes comme une fonction native d'ACCESS (left(), replace(), iif()...)

Pour des informations sur l'enchainement des événements ou pour faire joujou avec regarde le chasseur d'événement sur ma page perso. C'est de l'OpenSource prêt à l'emploi.

Le recordset :
C'est un objet purement VBA (DAO ou ADO) il permet de créer un accès sur les données (données d'une table ou d'une requête) toutes les actions (ajout, recherche, modif, suppression, enregistrement, déplacement...) sont conditionnées par des méthodes (Add, update, find, Move...) donc rien d'automatique tout est controlable et à controler par le code.

Je pense avoir fait une petite synthèse sur ce vaste sujet.
09/04/2006, 21h56
zephyr59

Merci pour ce concentré d'enseignement théorique.

1) Pour ce qui du chasseur d'évènement, j'ai un souci à l'ouverture de la base. Aurais tu construit ton appli sur une version supérieure à ACCESS 2000 ?

Descrption du message d'erreur : "le format de cette base est inconnu"

2) Peux tu me dire, s'il existe des illustrations de gestion mixte de formulaire : création du formulaire par l'assistant & alimentation des controles par du code VBA ?
10/04/2006, 08h05
JOAMY

Meme pb pour moi en ce qui concerne le chasseur d'évènement :cry:
Je suis aussi en 2000
10/04/2006, 09h53
loufab

effectivement il est en v2002.

Je vais vous faire une conversion et le mettre à dispo.

EDIT : C'est fait même lien, pour ceux qui ont Access 2002 ils feront la conversion.
10/04/2006, 10h35
loufab

Citation:

Envoyé par zephyr59

2) Peux tu me dire, s'il existe des illustrations de gestion mixte de formulaire : création du formulaire par l'assistant & alimentation des controles par du code VBA ?

Je ne pense pas qu'il existe sur developpez.com ce genre de chose synthétisé. Il faut faire un regroupement de plusieurs FAQ et Tutos.

L'alimentation des contrôles par VBA n'est pas une solution envisagé car elle redondante avec le fonctionnement natif d'access.
(Déclaration de la source, mise en place des controles faisant référence par la propriété Source à la source générale du Formulaire (ou état).)

Le DAO ou ADO intervient surtout dans les cas ou la requête n'est plus envisageable ou ne se justifie pas.
Recherche de trou dans une numérotation (exemple du résultat dans BDTEK -attention le code n'est pas ouvert-) c'est le cas typique d'une opération inter-enregistrement. Ce qu'une requête ne fait pas.

On l'utilise très rarement dans un formulaire, dans un état on peut le rencontrer plus souvent :
Mise en place d'un tag Imprimé lors de l'impression de la page.
Conception d'une table de matière... (voir mon tuto table des matières)
...
10/04/2006, 15h04
Tofalu

Un exemple interressant de formulaire alimenté en VBA :

http://access.developpez.com/sources...frms#GetRowDAO

:wink: