Comment élaborer une numérotation de facture sans "trou" ni doublon dans une
appli en réseau (2 utilisateurs simultanés) ?
Une numérotation par numauto génère des "trous" en cas d'annulation
d'enregistrement
J'ai pensé utiliser un champ "nofact" de type "entier" que je
n'incrémenterais qu'à la sortie du formulaire grace à un calcul du type
DMax("[NoFact]", "table factures")) + 1... mais je ne sais pas ce qu'il
risque de se passer en cas de conflit entre utilisateurs (non pas qu'ils se
tapent dessus, mais qu'il valident la facture au même moment...)
Est-ce la bonne approche
Je pense ne pas être le premier à me poser cette question, mais je n'ai rien
trouvé dans mes recherches...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-François
En complément de mon post précédent :
je ne sais comment incrémenter le numéro "à la sortie du formulaire" comme exposé dans la seconde solution : si je ferme et que tout de suite aprés je récupère le dernier enregistrement pour incrémenter le numéro, je crais que dans ce trés court laps de temps un autre utilisateur ait réussi à glisser une autrre ligne de facture...
bref, je patauge un peu...
merci de votre aide,
JF
"Jean-François" a écrit dans le message de news: 43fb2aec$0$29200$
Bonjour,
Comment élaborer une numérotation de facture sans "trou" ni doublon dans une appli en réseau (2 utilisateurs simultanés) ?
Une numérotation par numauto génère des "trous" en cas d'annulation d'enregistrement J'ai pensé utiliser un champ "nofact" de type "entier" que je n'incrémenterais qu'à la sortie du formulaire grace à un calcul du type DMax("[NoFact]", "table factures")) + 1... mais je ne sais pas ce qu'il risque de se passer en cas de conflit entre utilisateurs (non pas qu'ils se tapent dessus, mais qu'il valident la facture au même moment...)
Est-ce la bonne approche Je pense ne pas être le premier à me poser cette question, mais je n'ai rien trouvé dans mes recherches...
Merci de votre aide, JF
En complément de mon post précédent :
je ne sais comment incrémenter le numéro "à la sortie du formulaire" comme
exposé dans la seconde solution : si je ferme et que tout de suite aprés je
récupère le dernier enregistrement pour incrémenter le numéro, je crais que
dans ce trés court laps de temps un autre utilisateur ait réussi à glisser
une autrre ligne de facture...
bref, je patauge un peu...
merci de votre aide,
JF
"Jean-François" <xxxjfpweb@wanadoo.fr> a écrit dans le message de news:
43fb2aec$0$29200$8fcfb975@news.wanadoo.fr...
Bonjour,
Comment élaborer une numérotation de facture sans "trou" ni doublon dans
une appli en réseau (2 utilisateurs simultanés) ?
Une numérotation par numauto génère des "trous" en cas d'annulation
d'enregistrement
J'ai pensé utiliser un champ "nofact" de type "entier" que je
n'incrémenterais qu'à la sortie du formulaire grace à un calcul du type
DMax("[NoFact]", "table factures")) + 1... mais je ne sais pas ce qu'il
risque de se passer en cas de conflit entre utilisateurs (non pas qu'ils
se tapent dessus, mais qu'il valident la facture au même moment...)
Est-ce la bonne approche
Je pense ne pas être le premier à me poser cette question, mais je n'ai
rien trouvé dans mes recherches...
je ne sais comment incrémenter le numéro "à la sortie du formulaire" comme exposé dans la seconde solution : si je ferme et que tout de suite aprés je récupère le dernier enregistrement pour incrémenter le numéro, je crais que dans ce trés court laps de temps un autre utilisateur ait réussi à glisser une autrre ligne de facture...
bref, je patauge un peu...
merci de votre aide,
JF
"Jean-François" a écrit dans le message de news: 43fb2aec$0$29200$
Bonjour,
Comment élaborer une numérotation de facture sans "trou" ni doublon dans une appli en réseau (2 utilisateurs simultanés) ?
Une numérotation par numauto génère des "trous" en cas d'annulation d'enregistrement J'ai pensé utiliser un champ "nofact" de type "entier" que je n'incrémenterais qu'à la sortie du formulaire grace à un calcul du type DMax("[NoFact]", "table factures")) + 1... mais je ne sais pas ce qu'il risque de se passer en cas de conflit entre utilisateurs (non pas qu'ils se tapent dessus, mais qu'il valident la facture au même moment...)
Est-ce la bonne approche Je pense ne pas être le premier à me poser cette question, mais je n'ai rien trouvé dans mes recherches...
Merci de votre aide, JF
3stone
Salut,
"Jean-François" | En complément de mon post précédent : | | je ne sais comment incrémenter le numéro "à la sortie du formulaire" comme | exposé dans la seconde solution : si je ferme et que tout de suite aprés je | récupère le dernier enregistrement pour incrémenter le numéro, je crais que | dans ce trés court laps de temps un autre utilisateur ait réussi à glisser | une autrre ligne de facture...
Ta seconde méthode est la bonne, le champ étant bien sûr clé primaire!
Mais, pour éviter les problèmes en réseau, il te faut une bonne gestion d'erreur. Car c'est là que réside la solution !
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro est "pris" par un autre, tu obtiendra une erreur... Erreur que tu dois intercepter et utiliser pour relancer ta demande de numéro... jusqu'à ce qu'il soit accepté et donc "unique" (et sans trous ;-)
A+ Pierre
Salut,
"Jean-François"
| En complément de mon post précédent :
|
| je ne sais comment incrémenter le numéro "à la sortie du formulaire" comme
| exposé dans la seconde solution : si je ferme et que tout de suite aprés je
| récupère le dernier enregistrement pour incrémenter le numéro, je crais que
| dans ce trés court laps de temps un autre utilisateur ait réussi à glisser
| une autrre ligne de facture...
Ta seconde méthode est la bonne, le champ étant bien sûr clé primaire!
Mais, pour éviter les problèmes en réseau, il te faut une bonne gestion d'erreur.
Car c'est là que réside la solution !
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro
est "pris" par un autre, tu obtiendra une erreur...
Erreur que tu dois intercepter et utiliser pour relancer ta demande de numéro...
jusqu'à ce qu'il soit accepté et donc "unique" (et sans trous ;-)
"Jean-François" | En complément de mon post précédent : | | je ne sais comment incrémenter le numéro "à la sortie du formulaire" comme | exposé dans la seconde solution : si je ferme et que tout de suite aprés je | récupère le dernier enregistrement pour incrémenter le numéro, je crais que | dans ce trés court laps de temps un autre utilisateur ait réussi à glisser | une autrre ligne de facture...
Ta seconde méthode est la bonne, le champ étant bien sûr clé primaire!
Mais, pour éviter les problèmes en réseau, il te faut une bonne gestion d'erreur. Car c'est là que réside la solution !
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro est "pris" par un autre, tu obtiendra une erreur... Erreur que tu dois intercepter et utiliser pour relancer ta demande de numéro... jusqu'à ce qu'il soit accepté et donc "unique" (et sans trous ;-)
A+ Pierre
Jean-François
je ne suis pas sûr de bien comprendre... (il faut me tenir par la main, ce n'est pas la première fois que tu le fais ;-) )
1. quand tu dis :
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro est "pris" par un autre,... j'en déduis que le mon numéro de facture est attribué dès le début de la
saisie avec mon DMax, et non pas au moment où je ferme le formulaire... ai-je bien compris ?
2. jusqu'ici, j'avais un champ index facture en num auto, et un champ numéro facture distinct... je vois bien l'intêret de mettre ma clé primaire sur le numéro de facture et non pas sur mon index (dont je pourrais me passer) pour éviter les doublons... MAIS !... comme je vais constrire un sous formulaire (détail facture : liste des articles facturés) dont le lien se fera précisément par le "numéro de facture - clé primaire" (au lieu de l'index facture - clé primaire), ne risquè-je pas de compliquer beaucoup les choses, surtout si je dois intercepter des messages d'erreur ici ou là comme au ball trap...
3. tu me parles de relancer la demande de numéro de facture... j'ai de plus en plus de mal à visualiser là...
bref, le brouillard est moins dense que tout à l'heure, mais j'ai encore peur de me prendre un arbre dans la figure...
Merci de ton aide JF
"3stone" a écrit dans le message de news: O1OxI$
Salut,
"Jean-François" | En complément de mon post précédent : | | je ne sais comment incrémenter le numéro "à la sortie du formulaire" comme | exposé dans la seconde solution : si je ferme et que tout de suite aprés je | récupère le dernier enregistrement pour incrémenter le numéro, je crais que | dans ce trés court laps de temps un autre utilisateur ait réussi à glisser | une autrre ligne de facture...
Ta seconde méthode est la bonne, le champ étant bien sûr clé primaire!
Mais, pour éviter les problèmes en réseau, il te faut une bonne gestion d'erreur. Car c'est là que réside la solution !
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro est "pris" par un autre, tu obtiendra une erreur... Erreur que tu dois intercepter et utiliser pour relancer ta demande de numéro... jusqu'à ce qu'il soit accepté et donc "unique" (et sans trous ;-)
A+ Pierre
je ne suis pas sûr de bien comprendre...
(il faut me tenir par la main, ce n'est pas la première fois que tu le fais
;-) )
1. quand tu dis :
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro
est "pris" par un autre,...
j'en déduis que le mon numéro de facture est attribué dès le début de la
saisie avec mon DMax, et non pas au moment où je ferme le formulaire...
ai-je bien compris ?
2. jusqu'ici, j'avais un champ index facture en num auto, et un champ numéro
facture distinct... je vois bien l'intêret de mettre ma clé primaire sur le
numéro de facture et non pas sur mon index (dont je pourrais me passer) pour
éviter les doublons... MAIS !... comme je vais constrire un sous formulaire
(détail facture : liste des articles facturés) dont le lien se fera
précisément par le "numéro de facture - clé primaire" (au lieu de l'index
facture - clé primaire), ne risquè-je pas de compliquer beaucoup les choses,
surtout si je dois intercepter des messages d'erreur ici ou là comme au ball
trap...
3. tu me parles de relancer la demande de numéro de facture... j'ai de plus
en plus de mal à visualiser là...
bref, le brouillard est moins dense que tout à l'heure, mais j'ai encore
peur de me prendre un arbre dans la figure...
Merci de ton aide
JF
"3stone" <3stone_@_skynet_be> a écrit dans le message de news:
O1OxI$vNGHA.1192@TK2MSFTNGP11.phx.gbl...
Salut,
"Jean-François"
| En complément de mon post précédent :
|
| je ne sais comment incrémenter le numéro "à la sortie du formulaire"
comme
| exposé dans la seconde solution : si je ferme et que tout de suite aprés
je
| récupère le dernier enregistrement pour incrémenter le numéro, je crais
que
| dans ce trés court laps de temps un autre utilisateur ait réussi à
glisser
| une autrre ligne de facture...
Ta seconde méthode est la bonne, le champ étant bien sûr clé primaire!
Mais, pour éviter les problèmes en réseau, il te faut une bonne gestion
d'erreur.
Car c'est là que réside la solution !
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro
est "pris" par un autre, tu obtiendra une erreur...
Erreur que tu dois intercepter et utiliser pour relancer ta demande de
numéro...
jusqu'à ce qu'il soit accepté et donc "unique" (et sans trous ;-)
je ne suis pas sûr de bien comprendre... (il faut me tenir par la main, ce n'est pas la première fois que tu le fais ;-) )
1. quand tu dis :
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro est "pris" par un autre,... j'en déduis que le mon numéro de facture est attribué dès le début de la
saisie avec mon DMax, et non pas au moment où je ferme le formulaire... ai-je bien compris ?
2. jusqu'ici, j'avais un champ index facture en num auto, et un champ numéro facture distinct... je vois bien l'intêret de mettre ma clé primaire sur le numéro de facture et non pas sur mon index (dont je pourrais me passer) pour éviter les doublons... MAIS !... comme je vais constrire un sous formulaire (détail facture : liste des articles facturés) dont le lien se fera précisément par le "numéro de facture - clé primaire" (au lieu de l'index facture - clé primaire), ne risquè-je pas de compliquer beaucoup les choses, surtout si je dois intercepter des messages d'erreur ici ou là comme au ball trap...
3. tu me parles de relancer la demande de numéro de facture... j'ai de plus en plus de mal à visualiser là...
bref, le brouillard est moins dense que tout à l'heure, mais j'ai encore peur de me prendre un arbre dans la figure...
Merci de ton aide JF
"3stone" a écrit dans le message de news: O1OxI$
Salut,
"Jean-François" | En complément de mon post précédent : | | je ne sais comment incrémenter le numéro "à la sortie du formulaire" comme | exposé dans la seconde solution : si je ferme et que tout de suite aprés je | récupère le dernier enregistrement pour incrémenter le numéro, je crais que | dans ce trés court laps de temps un autre utilisateur ait réussi à glisser | une autrre ligne de facture...
Ta seconde méthode est la bonne, le champ étant bien sûr clé primaire!
Mais, pour éviter les problèmes en réseau, il te faut une bonne gestion d'erreur. Car c'est là que réside la solution !
Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro est "pris" par un autre, tu obtiendra une erreur... Erreur que tu dois intercepter et utiliser pour relancer ta demande de numéro... jusqu'à ce qu'il soit accepté et donc "unique" (et sans trous ;-)
A+ Pierre
3stone
Salut,
"Jean-François" | 1. quand tu dis : | > Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro | > est "pris" par un autre,... | j'en déduis que le mon numéro de facture est attribué dès le début de la | saisie avec mon DMax, et non pas au moment où je ferme le formulaire... | ai-je bien compris ?
Cela dépend ou tu place ton DMax()... si tu le place en valeur par défaut du textbox, oui, il y est attribué, et non si tu le fait à la sauvegarde de l'enregistrement.
| 2. jusqu'ici, j'avais un champ index facture en num auto, et un champ numéro | facture distinct... je vois bien l'intêret de mettre ma clé primaire sur le | numéro de facture et non pas sur mon index (dont je pourrais me passer) pour | éviter les doublons... MAIS !... comme je vais constrire un sous formulaire | (détail facture : liste des articles facturés) dont le lien se fera | précisément par le "numéro de facture - clé primaire" (au lieu de l'index | facture - clé primaire), ne risquè-je pas de compliquer beaucoup les choses, | surtout si je dois intercepter des messages d'erreur ici ou là comme au ball | trap...
il faut sauver l'enregistrement du form principal pour attribuer définitivement le numéro de facture, ensuite complèter le détail...
| 3. tu me parles de relancer la demande de numéro de facture... j'ai de plus | en plus de mal à visualiser là...
pendant ta saisie (le numéro étant attrbué) va dans ta table et ajoute ce numéro à la main... tu veras que Access te signale une erreur en disant que "ton" numéro Max existe déjà ! Récupère le numéro de l'erreur et puis tu t'en sert pour faire ta gestion d'erreur. Gestion d'erreur dans laquelle tu refait un DMax() dans le cas ou tu récupère ce fameux numéro d'erreur.
"Jean-François"
| 1. quand tu dis :
| > Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro
| > est "pris" par un autre,...
| j'en déduis que le mon numéro de facture est attribué dès le début de la
| saisie avec mon DMax, et non pas au moment où je ferme le formulaire...
| ai-je bien compris ?
Cela dépend ou tu place ton DMax()...
si tu le place en valeur par défaut du textbox, oui, il y est attribué,
et non si tu le fait à la sauvegarde de l'enregistrement.
| 2. jusqu'ici, j'avais un champ index facture en num auto, et un champ numéro
| facture distinct... je vois bien l'intêret de mettre ma clé primaire sur le
| numéro de facture et non pas sur mon index (dont je pourrais me passer) pour
| éviter les doublons... MAIS !... comme je vais constrire un sous formulaire
| (détail facture : liste des articles facturés) dont le lien se fera
| précisément par le "numéro de facture - clé primaire" (au lieu de l'index
| facture - clé primaire), ne risquè-je pas de compliquer beaucoup les choses,
| surtout si je dois intercepter des messages d'erreur ici ou là comme au ball
| trap...
il faut sauver l'enregistrement du form principal pour attribuer définitivement
le numéro de facture, ensuite complèter le détail...
| 3. tu me parles de relancer la demande de numéro de facture... j'ai de plus
| en plus de mal à visualiser là...
pendant ta saisie (le numéro étant attrbué) va dans ta table et ajoute
ce numéro à la main... tu veras que Access te signale une erreur
en disant que "ton" numéro Max existe déjà !
Récupère le numéro de l'erreur et puis tu t'en sert pour faire ta gestion d'erreur.
Gestion d'erreur dans laquelle tu refait un DMax() dans le cas ou tu récupère
ce fameux numéro d'erreur.
"Jean-François" | 1. quand tu dis : | > Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro | > est "pris" par un autre,... | j'en déduis que le mon numéro de facture est attribué dès le début de la | saisie avec mon DMax, et non pas au moment où je ferme le formulaire... | ai-je bien compris ?
Cela dépend ou tu place ton DMax()... si tu le place en valeur par défaut du textbox, oui, il y est attribué, et non si tu le fait à la sauvegarde de l'enregistrement.
| 2. jusqu'ici, j'avais un champ index facture en num auto, et un champ numéro | facture distinct... je vois bien l'intêret de mettre ma clé primaire sur le | numéro de facture et non pas sur mon index (dont je pourrais me passer) pour | éviter les doublons... MAIS !... comme je vais constrire un sous formulaire | (détail facture : liste des articles facturés) dont le lien se fera | précisément par le "numéro de facture - clé primaire" (au lieu de l'index | facture - clé primaire), ne risquè-je pas de compliquer beaucoup les choses, | surtout si je dois intercepter des messages d'erreur ici ou là comme au ball | trap...
il faut sauver l'enregistrement du form principal pour attribuer définitivement le numéro de facture, ensuite complèter le détail...
| 3. tu me parles de relancer la demande de numéro de facture... j'ai de plus | en plus de mal à visualiser là...
pendant ta saisie (le numéro étant attrbué) va dans ta table et ajoute ce numéro à la main... tu veras que Access te signale une erreur en disant que "ton" numéro Max existe déjà ! Récupère le numéro de l'erreur et puis tu t'en sert pour faire ta gestion d'erreur. Gestion d'erreur dans laquelle tu refait un DMax() dans le cas ou tu récupère ce fameux numéro d'erreur.
Je vais tester tout ça pour dissiper les dernières napes de brume... mais, comme d'hab', du éclaires grandement ma lanterne
à suivre... merci de ton aide !
"3stone" a écrit dans le message de news:
Salut,
"Jean-François" | 1. quand tu dis : | > Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro | > est "pris" par un autre,... | j'en déduis que le mon numéro de facture est attribué dès le début de la | saisie avec mon DMax, et non pas au moment où je ferme le formulaire... | ai-je bien compris ?
Cela dépend ou tu place ton DMax()... si tu le place en valeur par défaut du textbox, oui, il y est attribué, et non si tu le fait à la sauvegarde de l'enregistrement.
| 2. jusqu'ici, j'avais un champ index facture en num auto, et un champ numéro | facture distinct... je vois bien l'intêret de mettre ma clé primaire sur le | numéro de facture et non pas sur mon index (dont je pourrais me passer) pour | éviter les doublons... MAIS !... comme je vais constrire un sous formulaire | (détail facture : liste des articles facturés) dont le lien se fera | précisément par le "numéro de facture - clé primaire" (au lieu de l'index | facture - clé primaire), ne risquè-je pas de compliquer beaucoup les choses, | surtout si je dois intercepter des messages d'erreur ici ou là comme au ball | trap...
il faut sauver l'enregistrement du form principal pour attribuer définitivement le numéro de facture, ensuite complèter le détail...
| 3. tu me parles de relancer la demande de numéro de facture... j'ai de plus | en plus de mal à visualiser là...
pendant ta saisie (le numéro étant attrbué) va dans ta table et ajoute ce numéro à la main... tu veras que Access te signale une erreur en disant que "ton" numéro Max existe déjà ! Récupère le numéro de l'erreur et puis tu t'en sert pour faire ta gestion d'erreur. Gestion d'erreur dans laquelle tu refait un DMax() dans le cas ou tu récupère ce fameux numéro d'erreur.
Je vais tester tout ça pour dissiper les dernières napes de brume...
mais, comme d'hab', du éclaires grandement ma lanterne
à suivre...
merci de ton aide !
"3stone" <3stone_@_skynet_be> a écrit dans le message de news:
eDW2EAxNGHA.2920@TK2MSFTNGP10.phx.gbl...
Salut,
"Jean-François"
| 1. quand tu dis :
| > Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro
| > est "pris" par un autre,...
| j'en déduis que le mon numéro de facture est attribué dès le début de la
| saisie avec mon DMax, et non pas au moment où je ferme le formulaire...
| ai-je bien compris ?
Cela dépend ou tu place ton DMax()...
si tu le place en valeur par défaut du textbox, oui, il y est attribué,
et non si tu le fait à la sauvegarde de l'enregistrement.
| 2. jusqu'ici, j'avais un champ index facture en num auto, et un champ
numéro
| facture distinct... je vois bien l'intêret de mettre ma clé primaire sur
le
| numéro de facture et non pas sur mon index (dont je pourrais me passer)
pour
| éviter les doublons... MAIS !... comme je vais constrire un sous
formulaire
| (détail facture : liste des articles facturés) dont le lien se fera
| précisément par le "numéro de facture - clé primaire" (au lieu de
l'index
| facture - clé primaire), ne risquè-je pas de compliquer beaucoup les
choses,
| surtout si je dois intercepter des messages d'erreur ici ou là comme au
ball
| trap...
il faut sauver l'enregistrement du form principal pour attribuer
définitivement
le numéro de facture, ensuite complèter le détail...
| 3. tu me parles de relancer la demande de numéro de facture... j'ai de
plus
| en plus de mal à visualiser là...
pendant ta saisie (le numéro étant attrbué) va dans ta table et ajoute
ce numéro à la main... tu veras que Access te signale une erreur
en disant que "ton" numéro Max existe déjà !
Récupère le numéro de l'erreur et puis tu t'en sert pour faire ta gestion
d'erreur.
Gestion d'erreur dans laquelle tu refait un DMax() dans le cas ou tu
récupère
ce fameux numéro d'erreur.
Je vais tester tout ça pour dissiper les dernières napes de brume... mais, comme d'hab', du éclaires grandement ma lanterne
à suivre... merci de ton aide !
"3stone" a écrit dans le message de news:
Salut,
"Jean-François" | 1. quand tu dis : | > Si, entre le début de saisie de ta facture et sa sauvegarde, le numéro | > est "pris" par un autre,... | j'en déduis que le mon numéro de facture est attribué dès le début de la | saisie avec mon DMax, et non pas au moment où je ferme le formulaire... | ai-je bien compris ?
Cela dépend ou tu place ton DMax()... si tu le place en valeur par défaut du textbox, oui, il y est attribué, et non si tu le fait à la sauvegarde de l'enregistrement.
| 2. jusqu'ici, j'avais un champ index facture en num auto, et un champ numéro | facture distinct... je vois bien l'intêret de mettre ma clé primaire sur le | numéro de facture et non pas sur mon index (dont je pourrais me passer) pour | éviter les doublons... MAIS !... comme je vais constrire un sous formulaire | (détail facture : liste des articles facturés) dont le lien se fera | précisément par le "numéro de facture - clé primaire" (au lieu de l'index | facture - clé primaire), ne risquè-je pas de compliquer beaucoup les choses, | surtout si je dois intercepter des messages d'erreur ici ou là comme au ball | trap...
il faut sauver l'enregistrement du form principal pour attribuer définitivement le numéro de facture, ensuite complèter le détail...
| 3. tu me parles de relancer la demande de numéro de facture... j'ai de plus | en plus de mal à visualiser là...
pendant ta saisie (le numéro étant attrbué) va dans ta table et ajoute ce numéro à la main... tu veras que Access te signale une erreur en disant que "ton" numéro Max existe déjà ! Récupère le numéro de l'erreur et puis tu t'en sert pour faire ta gestion d'erreur. Gestion d'erreur dans laquelle tu refait un DMax() dans le cas ou tu récupère ce fameux numéro d'erreur.
