Comment gérer 2 champs num auto

Bonsoir à tous,

je voudrai avoir 2 champs numauto dans un même formulaire. je crois que cela est impossible. L'idée est d'avoir en plus du 1er champs numauto d'avoir un autre champs qui s'incrémente automatiquement en fonction du contenu d'un autre champs. Par exemple. j'ai dans une base courrier un 1er champ numauto qui sert de référence à tous les enregistrements. j'ai besoin d'avoir un 2° champ numauto uniquement pour les documents d'un type défini. je n'ai pas de solution .... Qui peut m'aider.....

En effet tu ne peux pas avoir 2 numéros automatiques pour une même table et tu ne peux pas non plus avoir des numéros automatiques conditionnés (par exemple pour un type de produit donné).

Il faut que tu le gère toi même.

Ta base va-t-elle être utilisée par plus d'une personne à la fois ?

A+

Y a t il une solution codée pour pouvoir gérer ce champ automatiquement ? Sinon cette appli fonctionne en réseau et sera utilisée par plusieurs personnes

Je ne t'ai pas oublié.

Il y a plusieurs discussions sur ce sujet dans le forum mais je n'ai pas eu le temps de faire une recherche. Je devrais être capable de le faire jeudi soir (heure du Québec) prochain.

A+

Voici 3 discussions sur le sujet.

http://www.developpez.net/forums/d84...menter-champs/

http://www.developpez.net/forums/d26...-numerotation/

http://www.developpez.net/forums/d22...s-sous-access/

A+

j'ai un peu de mal a comprendre la syntaxe dans les liens mentionnés. Pour faire clair et simple, mon besoin est :

j'ai une BDD courrier. Dans ma table courrier j'ai un champs numauto d'enregistrement de tous mes courriers. Dans cette base de courrier j'ai différents type de courrier (lettres, messages, etc .....) je voudrai avoir dans ma table un deuxième champs qui s'incrémente automatiquement uniquement pour les courrier de type Message. Existe t-il une solution ?

bonsoir,

tu peux gérer la numérotation en toute indépendance de ta table Courrier avec une table supplémentaire:

NumeroTypeCourrier( #idTypeCourrier, ProchainNumero)

Code:

---

1 2 3 4 5

idTypeCourrier prochainNumero 1 12 2 8 3 25 ...

---

par exemple, tu crées un nouveau courrier de type 2. Il faut donc lui attribuer le numéro 8.
Tu te dépêches alors de mettre à jour prochainNumero=8+1=9 pour le type n°2 avant qu'un autre utilisateur te piques le même numéro 8 (si tu as tiré le numéro 8, il doit être définitivement cramé).

C'est assez simple à gérer je trouve mais il y a peut-être mieux...

f-leb,

j'aimerai trouver une solution sous code pour que les utilisateurs n'aient pas à s'en soucier....

bonjour,

oui bien entendu il faut gérer tout ça par code mais j'essayais de mettre en place le principe dans un premier temps.

Apparemment tu n'as qu'un seul type de message à prendre en compte donc la table supplémentaire aurait plutôt la structure:

CompteurMessage( NumeroCompteur) (un seul champ, une seule ligne)

Le point délicat est le choix de l'évènement de formulaire qui va attribuer le numéro au courrier et incrémenter le compteur:

(je suppose que tu as un champ TypeCourrier dans ta table Courrier)


- soit tu attribues le numéro à ton courrier dès que le champ TypeCourrier est remplie avec la valeur "Message" (et tu incrémentes aussitôt le compteur dans CompteurMessage pour éviter qu'un autre utilisateur ne te pique ton numéro).

- Soit tu attribues le numéro à la fin de la saisie et sur validation d'un courrier de type "message". Le problème c'est que l'utilisateur ne voit pas le numéro attribué au début de la saisie.

- soit tu attribues un numéro "probable" en début de saisie dès que le champ TypeCourrier est renseigné sur la valeur "message". Lorsque tu valides le courrier à la fin de la saisie, il faut vérifier que le numéro "probable" n'ait pas été attribué à un autre utilisateur plus rapide que toi. Si ça se produit, il faut changer le numéro en prévenant l'utilisateur et mettre à jour le compteur.

tu vois l'idée ? Sur quelle solution tu partirais ?

Bonjour brutus437, marot_r et f-leb,

Je me permets de m'imisser dans ce fil concernant les remarques judicieuses de f-leb.

Il me semble que la fonction Dmax(), que Claude m'a fait découvrir, conviendrait bien et éviterait la création d'une table, non ?
Certes, le temps de réponse du Dmax() peut être important suivant la taille de la table, mais bon, à tester.

Concernant les choix que tu proposes, perso, je penche pour :

Citation:

---

- Soit tu attribues le numéro à la fin de la saisie et sur validation d'un courrier de type "message". Le problème c'est que l'utilisateur ne voit pas le numéro attribué au début de la saisie.

---

avec un message d'information, après insertion du record, qui informe l'utilisateur du n° affecté.

Enfin, juste une idée :

• créer un index unique sur le couple Type_message/Numero ;
• dans le code, "intercepter" l'erreur gérée par Access concernant l'éventuel doublon ;
• recommencer la recherche du Dmax().

==> En fait, une boucle sur recherche Dmax() et INSERT tant que "erreur Access".

bonjour Richard,

Citation:

---

Envoyé par Richard_35

Il me semble que la fonction Dmax(), que Claude m'a fait découvrir, conviendrait bien et éviterait la création d'une table, non ?

---

il faut alors envisager les conséquences de certains scénarios (catastrophe).

Scénario 1:
-Je créée un message n°35 et réalise un certain nombre de traitements dessus.
-Par erreur (clavier qui fourche), je détruis malencontreusement le message n°35. Vite vite, il faut le recréer !!
- oui mais pendant ce temps là, un autre utilisateur créé un nouveau message dont le numéro attribué avec le Dmax sera... le n°35.

Résultat: le message initialement référencé avec le n°35 et détruit par erreur a été attribué à un autre message...

Scénario 2:
la table des courriers devient un peu volumineuse et je souhaite archiver les messages n°1 à n°35000 dans une base d'archivage mais tout en pouvant les récupérer dans la base principale si nécessaire.
Dans la base principale, la table des courriers est donc vidée après archivage.
Avec Dmax, le compteur redémarre donc à 1.
Je créée de nouveaux messages n°1, n°2,....,N°120 et là je veux rapatrier le message n°12 depuis les archives. Cata, il y a déjà un n°12...

C'est pour ça que je proposais de gérer l'incrément indépendamment dans une autre table.
Dans le 1er scénario, même si l'enregistrement n°35 est détruit, le compteur stocké dans l'autre table est à 36.
Dans le 2ème scénario, si tu archives les n°1 à 35000, le compteur de l'autre table est resté à 35001.

En fait le but est de reproduire le comportement du NumeroAuto d'Access (si un numéro sort, il ne doit plus jamais ressortir).

Maintenant on ne connait pas bien, pour l'instant, l'utilité de ce numéro donc j'attends de voir vers quoi on doit s'engager:aie:...

Ce que tu dis, f-leb, est frappé du bon sens... comme d'habitude : je m'incline, donc.

Donc, si ce numéro doit se propager dans d'autre(s) table(s) ou si le dernier numéro "temps réel" a des chances de se perdre à un moment ou à un autre, alors, il faut, effectivement, externaliser celui-ci : il faut qu'il soit grillé à tout jamais.

Merci à tous de vos infos et idées. Voici mes données

- une table "Tabcourrierdepart"
- un champs numauto "Chronodepart"
- un champs qui doit fonctionner comme numauto "nmrtsm"
- un champs "Typedoc"

Dans mon formulaire de saisie, je voudrai que :
- dès que je saisi dans le champs "Type doc" la valeur "MSG", le champs "nmrtsm" s'incrémente automatiquement. Cette valeur m'est indispensable et doit etre spécifique que pour ce type de courrier pour servir de référence pour le système servant à transmettre ces messages.

- le champs numauto "Chronodepart" s'incrémente systématiquement quelque soit le type de courrier enregistré.

Merci de me guider dans l'élaboration du code servant à paramétrer le champs "nrmtsm".

Puis je vous transmettre ma base de données pour vous permettre de vous faire plus précisément un idée ?

J'ai d'autres évolutions à intégrer dont je ne sais pas encore aujourd'hui comment les créer. (réinitialisation des champs numauto par compactage a la demande et non à chaque fermeture, car le fichier devient très gros en milieu d'année - faciliter le changement du password pour l'utilisateur etc...)

Merci ktir, comme on dit ici au Liban !!!!

bonsoir,

l'idée serait de rechercher le numéro après la mise à jour de [TypeDoc].

Si j'ai une table CompteurMSG avec un seul champ NumeroCompteur:

CompteurMSG:

Code:

---

1 2	NumeroCompteur 1

---

sur l'évènement "Après MAJ" de la zone de texte "TypeDoc", on écrit:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

Private Sub TypeDoc_AfterUpdate() ' Dim LeNouveauNumero As Long Dim rCompteurMsg As DAO.Recordset Dim db As DAO.Database: Set db = CurrentDb() ' If Me.TypeDoc = "MSG" Then Set rCompteurMsg = db.OpenRecordset("CompteurMSG") With rCompteurMsg .MoveFirst LeNouveauNumero = .Fields(0) .Edit .Fields(0) = LeNouveauNumero + 1 .Update End With ' rCompteurMsg.Close: Set rCompteurMsg = Nothing ' Me.nmrtsm = LeNouveauNumero ' End If ' db.Close: Set db = Nothing ' End Sub

---

Je laisse le soin aux spécialistes d'améliorer le code, mettre en place la gestion d'erreurs, gérer les accès concurrentiels etc...:aie:

F-leb

Je viens de tester ta solution, cela semble fonctionner, je prolonge le test pour voir. J'ai recopié bêtement les lignes de code. je n'en comprend pas complètement le fonctionnement. peux tu éclairer ma lanterne pour que je sois moins ignorant à l'avenir........ merci pour ton aide précieuse...

bonjour,

voir http://warin.developpez.com/access/dao/?page=partie_5 pour l'accès aux données via les recordSet.

F-Leb,

Encore merci pour ton aide, ta dernière solution fonctionne très bien.