Discussion :

[LeScandinave]

Bonjour,
ce post s'adresse à un peu tout le monde.

Je me rend compte en lisant les post du forum depuis quelques temps déjà que je n'utilise pas ACCESS pour ces fonctionnalités faciles à prendre en main, mais plutôt pour la possibilité qui est offerte de quasiment tout coder par VBA.

J'utilise notamment volontier des formulaires, des requêtes et tables créés dynamiquement.
Je n'utilise plus du tout de sous formulaires (pas facile à mettre en page, beaucoup de questions dessus, pas énormément de réponses. La FAQ n'en parle quasiment pas!).
Je n'utilise quasiment pas les options "création requête", réalise les calculs à l'aide de variable dans le code et non pas dans des requête "créées en dur".


J'aimerais un peu connaître l'avis de chacun sur sa façon d'utiliser Access?
Vous êtes plutôt Access pur et dur ou Access :support VBA?

Voilà, c'était la question qui me trotte dans la tête depuis quelques jours.

[cafeine]

Hello,

Pour ma part j'utilise des requêtes temporaires comme toi, créées par le code, je suis en revanche beaucoup plus mitigé sur les formulaires créés dynamiquement, même si je suis l'auteur d'un tutoriel qui en parle.

Je pense que tes calculs VBA pourraient peut être gagner en vitesse en utilisant un peu plus les ressources SQL du moteur JET, j'ai noté de nets gains de performance dans la pratique.

Bonne continuation

[LeScandinave]

Je dois avouer que sans www.developpez.net, je n'aurais jamais eu l'idée de faire des formulaires dynamiques, comme bien d'autres choses par le code d'ailleurs.

Sinon pour les calculs: il y a sûrement un problème de mon côté car je trouve ça peu pratique avec SQL. Je m'explique:
Par exemple, je prend une requête "qryListe" avec pleins de champs. Si par exemple je veux: compter les enregistrements avec une condition WHERE (en gros avoir des sous-sommes), compter l'ensemble des enregistrements (somme globale), puis calculer le pourcentage (sous-somme/somme*100), je devrais avoir 3 petites requêtes différentes (qui prennent de la place tout de même) pour arriver au résultat final (on peut peut-être en faire 2, mais là j'ai toujours pas trouvé )

Alors que si je prend mon code VBA, je crée 1 recordset et je calcule tout le reste avec des varibles temporaires. Je crée une table temporaire pour conserver mes résultats le temps du besoin, puis je supprime le tout dès que l'utilisateur ferme la Base par exemple.

Alors après, savoir s'il faut favoriser le dixième de secondes ou la place sur un réseau ou sur un poste fixe, je pense que cela dépend du besoin client.


Et personnellement, je trouve beaucoup intéressant de toucher à VBA car si on ne comprend pas ce que l'on fait, ça plante avec un message d'erreur assez explicite bien souvent. En SQL, on peut faire des choses qui fonctionnent sans forcément comprendre ce qui se cache derrière (c'est aussi un avantage d'ACCESS d'être très ACCESSible ) et donc si un jour ça plante, on reste devant un problème que l'on ne comprend pas (mauvais souvenirs comme beaucoup je pense...)

[Tofalu]

Pour ma part j'utilise des requêtes temporaires comme toi, créées par le code

C'est une pratique que j'utilise aussi fréquement. Elle n'est malheureusement pas recommandée et ce pour plusieurs raisons

Le fait de stocker une requete dans le code VBA impose une modification du code à chaque modification du résultat souhaité. Ce qui arrive fréquement lors des quelques jours suivant le recette. En outre cela évite donc la maintenance évolutive et corrective de l'application et je vous passe les contraintes de déployement dans le cadre de mde.

De plus les objets querydef de la base de données sont optimisées pour traiter les index des tables. On note ainsi une différence notoire entre

Code :

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

Db.OpenRecordset("SELECT * FROM Matable")

Et

Code :

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

Db.Querydefs("R01").OpenRecordset

Où R01 est évidemment la même requête qu'au dessus.

Enfin, dans le cadre d'insertion multiples, une requête INSERT est bien plus rapide qu'une accumulation de AddNew et Edit de recordset.

, je suis en revanche beaucoup plus mitigé sur les formulaires créés dynamiquement, même si je suis l'auteur d'un tutoriel qui en parle.

Tout le monde connait mon point de vue sur ces formulaires

Même si ton tuto est génial cafeine pour l'affichage pseudo continu, on peut pas faire autrement

Je pense que tes calculs VBA pourraient peut être gagner en vitesse en utilisant un peu plus les ressources SQL du moteur JET, j'ai noté de nets gains de performance dans la pratique.

Un réel problème lorsque l'on utilise VBA est justement la déclaration et la libération des objets. En outre les méthodes CurrentDb et CodeDB sont de véritables pièges. En effet à chaque appel, elle instancie un nouvel objet database correspondant au lieu de retourner celui utilisé. Et oui ce sont des fonctions et non des propriétés Set.

Ainsi, il ne faut pas tomber dans le piege du

Code :

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

1
2
3
While i<1200
  CurrentDb.Execute ...
Wend

Mais bien :

Code :

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

1
2
3
4
5
6
 
Dim Db as dao.database
set Db=CurrentDb
While i<1200
  Db.Execute ...
Wend

Dans le premier cas, à chaque passage dans le while un nouvel objet sera instancié et donc de la mémoire allouée ... et donc du ralentissement.

Enfin pour ce qui est des performances, je reste fidèle au bon vieux DAO qui a certes 3 versions de VB de retard mais qui est bien plus rapide que ADO dans le cadre d'une manipulation Jet

[LeScandinave]

Tout le monde connait mon point de vue sur ces formulaires

Oui, j'ai bien vu tes réponses sur le sujet. Mais tout de même je me suis lancé dedans car:
- mon appli (actuelle) ne sera pas utilisée avec RunTime, donc je peux me permettre quelques folies .
- je trouve dommage par exemple dans le Tuto "Définition et manipulation de données avec DAO" de Christophe WARIN au point 5.5.2. de créer des contrôle "en dur" alors qu'ils ne seront pas tous utilisés à tout moment.
Du point de vue de la conception, il me paraît plus logique de créer les contrôles dont on a besoin à un moment "t", plutôt que de tous les créer "en dur" et de jouer sur la propriété "visible" suivant les besoins...
Même s'il faut reconnaître que faire un formulaire de A à Z en dynamique, ça prend pas mal de ligne de code .

je me suis même amusé à créer des formulaires en dynamique en cascade (avec les procedures événementielles des boutons créés eux-mêmes dynamiquement), et bien je trouve ça amusant, cela permet de faire des choses un peu nouvelles, mais si c'est non conventionnels...
Ne pas tapper Tofalu

Enfin pour ce qui est des performances, je reste fidèle au bon vieux DAO qui a certes 3 versions de VB de retard mais qui est bien plus rapide que ADO dans le cadre d'une manipulation Jet

J'ai bien fait de commencer par DAO et donc de ne jamais toucher à ADO, car je n'ai jamais trouvé de comparatif sur ce forum. Tiens, je vais ouvrir Google moi, ça m'intéresse ça.

[Lou Pitchoun]

Bonjour,

Je n'ai mis les mains dans DAO que récemment....
Le temps de le maitriser un peu plus et je l'utiliserais plus qu'aujourd'hui.
J'utilise des requetes en durs si elle me servent de sources pour un publipostage sinon j'utilise le SQL. Tout dépend de l'utilisation.
Je n'ai pas encore eu la grande utilité de créer des formulaires ou états dynamiquement, mais pour la pérénité d'une application que l'utilisateur pourrait faire évoluer : je pense que ça devient utile pour éviter qu'il nous dérange pour "J'aimerais avoir ce type d'état.. vous pourriez me le faire pour dans 5 minutes ??"

Enfin, dans le cadre d'insertion multiples, une requête INSERT est bien plus rapide qu'une accumulation de AddNew et Edit de recordset

C'est ce que j'ai compris en parcourant ce forum et je suis en train de réécrire tous les codes faisant appel à Addnew et Edit.
Avant ça, je faisais des boucles... le truc "classique" mais pas performant le jour ou j'aurais 100 000 enregistrements à parcourir et à ne mettre à jour que 1000 d'entre eux.... surtout qu'il y a 90 % de chance qu'ils se trouvent parmi les derniers enregistrements

Voilà mon mot sur le sujet...

[Tofalu]

je trouve dommage par exemple dans le Tuto "Définition et manipulation de données avec DAO" de Christophe WARIN au point 5.5.2. de créer des contrôle "en dur" alors qu'ils ne seront pas tous utilisés à tout moment.

Quoi il te plait pas ton tuto ?

Oui tu as raison, sauf que la création dynamique de controle passe par une ouverture/fermeture obligatoire du formulaire. En gros une usine à gaz. De plus dans l'exemple de la lecture par bloc, on affiche 10 lignes par 10 lignes.

Dans la majorité des cas les dix lignes seront affichées. Aprés, on pourrait faire des tests de fiabilité et se rendre compte que le système est bien plus rapide ainsi qu'une modification systématique des controles.

C'est un peu comme la division par 0

Si j'ai

Code :

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

1
2
3
Sub test(a,b)
msgbox a/b
end sub

ça plantera si b=0

Que vaut il mieux faire ? Un test systématique ou une gestion d'exception ?

Code :

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

1
2
3
4
Sub test(a,b)
if b<>0 then _
msgbox a/b
end sub

Ce code a le mérite d'être "propre". Toutefois, il est trés peu probable que b soit égale à 0. Du coup, on préfera un code plus lourd mais plus performant

Code :

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

1
2
3
4
5
Sub test(a,b)
On error goto err
msgbox a/b
err
end sub

[LeScandinave]

Quoi il te plait pas ton tuto ?

si ton tuto me plaît, il m'a même formé à la DAO

(je vais faire court, ar j'ai effacé ma réponse bêtement et il est préférable de faire un résumé, car c'était bien long )

Je répèteque je suis conscient que créer un formulaire dynamiquement est très lourd en code...
Mais comme j'utilise cela plusieurs fois dans ma base, je suis en train de voir si la réalisation de petits modules permettrait d'alléger le code.

De plus avec une structure dynamique ont à énormément de liberté et je ne comprend pas pourquoi la maintenance est plus complexe.

En fait une base tout en code, même si elle est un peu plus lente, à un domaine d'utilisation si large:
- on peut aussi bien évaluer des patattes que des méthodes (ce que je fais en ce moment)
- on peut gérer aussi bien 100 enregistrements que 10 000.

Je suis sûr que l'on peut faire une structure de base ACCESS dynamique vide et par un formulaire de "paramètrage" bourré de variables publiques, définir les tables, les formulaires (polices, couleurs, etc) en fonction de l'utilisateur.

En fait, les programmeurs vous allez peut-être être , mais en réalisant une base de donnée, je permet à un service d'une entrepris de passer de 2 jours à 2 clicks pour réaliser une tâche, alors je me préoccupe peu de savoir si ces 2 clicks vont prendre 2 minutes pour donner un résultat ou 2 secondes.

Ce qui m'importe est :
- d'avoir un code aussi propre et homogène que possible (eh oui, car comme je ne suis pas du tout informaticien, je dois de temps en temps m'inspirer du forum ou de la FAQ, et en plus de trouver une solution, il faut qu'elle corresponde au reste de mon code).
- avoir un produit le plus proche des outils déjà utilisés par le futur utilisateur.
- prendre du plaisir à programmer en étant créatif (car ce n'est pas mon métier, ce sont juste mes stages qui me permettent de faire de l'ACCESS à haute dose, c'est-à-dire toute la journée tous les jours OUVRES ).

Mais il est vrai que je ne m'arrête pas au détails de ce genre:

Que vaut il mieux faire ? Un test systématique ou une gestion d'exception ?

Code :

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

1
2
3
4
Sub test(a,b) 
if b<>0 then _ 
msgbox a/b 
end sub

Ce code a le mérite d'être "propre". Toutefois, il est trés peu probable que b soit égale à 0. Du coup, on préfera un code plus lourd mais plus performant .

Code :

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

1
2
3
4
5
Sub test(a,b) 
On error goto err 
msgbox a/b 
err 
end sub

Si je trouve une optimisation sur le forum, j'en tiens compte, mais je ne m'y arrête pas pour trouver le plus performant, MAIS ça viendra avec les années, car plus j'apprendrai, plus je deviendrai exigeant, plus je chercherai la meilleures solutions!

Malheureusement, je n'en suis qu'à ma 3eme base de donnée de ma vie ... mais je suis ravi de vos réaction car par de petits débats comme ce post, on , les "petits amateurs de ACCESS", peut apprendre sur la "philosophie" qu'il faut adopter pour atteindre un résultat optimal, ce que l'on apprend malheureusement pas dans le jeu de questions réponses du forum.

J'attend encore d'autres points de vue, notamment de personnes utilisant ACCESS à l'occasion comme 95% (et encore je suis gentil je crois) des gens utilisant ce forum dont je fais partie!

[B.AF]

Modeste contribution,

Mais souvent, le soucis dans l'usage d'Acess vient de l'absence de réflexion.
On se met à créer des tables, quand ca va pas, on bidouille de requêtes.

Sur ce point, je n'utilise jamais les requêtes Access.

Déjà, le principe d'update et d'insert sans contexte transactionnel ne me satisfait pas.

En outre, j'utilise souvent des modules de classe pour me faciliter la vie.
Je mappe la classe avec les champs de la classe, avec les proprerty set et get, une procédure de chargement (généralement, je l'appel load), un update, un delete (pas tout le temps en plus).

Ca me permet surtout de mettre de vrais contrôles fonctionnels et surtout, même dans les formulaires de les délocaliser complêtement des tables. (pas de lien, juste des associations entre des composants et des propriétés de classe). Je vois déjà entendre OUHLALALA c'est lourd.
Et bien non, j'ai passé 2 heures à me faire un petit outil sous Excel qui génére le code depuis une table très bien. Donc je créé la table, petite moulinette Excel, et hop ! import de ma classe dans VBA.

En outre pour le code SQL, j'écris du code le plus simple possible.
Dans le modéle, je normalise au maximum.

Ca me permet d'éviter d'appeler les relations, les jointures, les outers, inner, et tout ces petits choses qui rendent SQL Jet un peu chiant.
J'essaye constamment de n'utiliser que :
SELECT, WHERE, AND, et LIKE (Et like, avec parcimonie)

Pour le reste, je préfére passer par des recordsets.
Pourquoi ?
En gros, ca me permet d'encapsuler la complexité des méthodes d'accès aux données, et si je veux un jour migrer la base, le code SQL est suffisamment simple pour n'avoir qu'à modifier la procédure de connexion à la base.

Pour le traitement des fichiers, j'utilise exclusivement le Scripting Runtime.

Et pour moi le pari est réussi : Le produit est portable, j'ai peu de gestion d'erreur à faire, et le code est plutôt uniforme.

[random]

y a sûrement un problème de mon côté car je trouve ça peu pratique avec SQL. Je m'explique:
Par exemple, je prend une requête "qryListe" avec pleins de champs. Si par exemple je veux: compter les enregistrements avec une condition WHERE (en gros avoir des sous-sommes), compter l'ensemble des enregistrements (somme globale), puis calculer le pourcentage (sous-somme/somme*100), je devrais avoir 3 petites requêtes différentes (qui prennent de la place tout de même) pour arriver au résultat final (on peut peut-être en faire 2, mais là j'ai toujours pas trouvé )

les fonctions de domaine permettent justement de faire cà très bien sans
devoir recourir à trois requêtes

[Tofalu]

SELECT, WHERE, AND, et LIKE (Et like, avec parcimonie)

Sauf que les jointures en JOIN sont bien plus recommandées et constitue une réelle amélioration de SQL et notamment au niveau des perfromances. Se contenter de jointure en =, c'est faire un pas de presque 20 ans en arrière (1986)

les fonctions de domaine permettent justement de faire cà très bien sans
devoir recourir à trois requêtes

Attention, c'est fonctions ( D* ) sont trés gourmandes en ressources. A utiliser avec parcimonie