Discussion :

[JackDelpoBxl]

Bonjour,
Nous migrons sur Access 2010 à partir de Access 2003. Donc beaucoup de changements à digérer en autodidacte :-)
Je devrais réécrire une petite application qui utilisait des macros. La DB est utilisée par 4 personnes. ( comporte un .mdb sur le serveur et 4 mdb client similaires) Un champ doit être structuré et comporter une partie incrémentée. Je vois sur le forum des raisons de NE PAS utiliser les macros au profit de VB.
Mais je découvre que des triggers permettent d'éviter les erreurs en laissant le moteur faire des actions.
Finalement est-ce qu'on utilise une macro sur la DB (serveur) ou du code VB sur les 4 clients.
Qu'est ce qui est le plus propre ?

Merci d'avance

[mumen]

Bonjour Jacques

Dois tu migrer ou dois tu réécrire ?

Normalement, le passage de 2003 à 2010 peut être fait en quelques clics de souris, et fin de l'histoire.

Sinon.

Les macros sont très bien pour les débutants. C'est une chose dont on décide toujours de se passer complètement quand on commence à savoir coder en VBA.

Les triggers sont une façon pauvre de coder mais une façon rigoureuse et solide parce que centrale. Ils concernent plus les règles d'intégrité que les actions complexes à effectuer sur les tables. Le VBA est un joujou particulièrement puissant pour dépatouiller toutes les situations à l'aide des objets formulaires et d'accès aux données (DAO), alors qu'avec les triggers tu vas des fois ramer à trouver la bonne solution. Le problème majeur, c'est de discerner la technique adéquate pour une solution donnée.

Si tu veux aller plus loin, tu peux faire une espèce d'audit rapide de ce dév, qui donne le type de choses qu'il réalise pour nous en donner une idée, qu'on puisse essayer de te guider plus ponctuellement.

PS : par définition la db server (dorsale) n'éxécute aucun autre code que les triggers : aucune macro, aucun VB.

[JackDelpoBxl]

Nous avons hérité d'une application non documentée qui faisait un large appel a des macros. La partie essentielle est le suivi du courrier IN et OUT et donc la génération d'un numéro structuré qui s'incrémente.

La migration de ce "bidule" qui date d'Access97 produit des erreurs et comme 80% ne correspond pas à nos besoins je pense la réécrire et utiliser des PC avec run-time 2010.

Mais je coince pour trouver la manière d'incrémenter un numéro dans le nouveau record d'une table. J'arrive à utiliser une macro pour calculer un champ au sein d'un même record, mais je ne vois pas si un trigger arriverait à mettre dans une variable la dernière valeur d'un champ et y ajouter 1 pour l'écrire dans l'enregistrement en cours. Et aussi éviter des erreurs lors d'accès simultanés.....

Je crois que ce problème n'est pas aussi simple que je le pensais.....
A+

[mumen]

Mais je coince pour trouver la manière d'incrémenter un numéro dans le nouveau record d'une table. J'arrive à utiliser une macro pour calculer un champ au sein d'un même record, mais je ne vois pas si un trigger arriverait à mettre dans une variable la dernière valeur d'un champ et y ajouter 1 pour l'écrire dans l'enregistrement en cours. Et aussi éviter des erreurs lors d'accès simultanés.....

Je crois que tout y est :

http://warin.developpez.com/tutoriel...s/numauto2010/