Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Applications Microsoft Office Access le numero auto est il inutile

le numero auto est il inutile

17 réponses
Avatar
loutox
Bonjour à tous

Sur une base access 2003, j'ai un champ num auto qui est la clé d'une table.
Or, pour je ne sais quelle raison, ce numero auto affecte à un nouvel
enregistrement une valeur existant deja dans la table.
grace aux conseils glanés ici (c'est le meilleur ng que je connaisse) le
probleme a ete resolu.

par ailleurs je vais desormais virer le num auto et utiliser à la place une
instruction du type "DMax("NumFact", "Table1") + 1" pour eviter ce genre de
problemes ainsi que des trous dans la numerotation.

Mais alors, si le numero auto n'est pas fiable, à quoi sert il ?

cordialement
Loutox.
Signaler un problème avec ce contenu

10 réponses

Supprimer
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
1 2
Avatar
J-Pierre
Bonjour :-)

"loutox" a écrit dans le message de news: 44926a04$0$4787$
Bonjour à tous

grace aux conseils glanés ici (c'est le meilleur ng que je connaisse)


Ca, c'est bien vrai, même si Tisane se fait rare :-(

par ailleurs je vais desormais virer le num auto et utiliser à la place une
instruction du type "DMax("NumFact", "Table1") + 1" pour eviter ce genre de problemes ainsi que des trous dans la numerotation.



Pourquoi les trous te gênent-ils ? Normalement, un numéroAuto est utilisé de manière interne par l'appli et n'est jamais visible par
l'utilisateur.

Virer le numéroAuto ? Quelle hérésie..... Ce n'est pas parce que tu as eu un problème qu'il faut réagir comme ça.....

Et puis, les fonctions de domaine (dmax, dcount, etc) côté performance, ce n'est pas le pied, il vaut mieux les éviter.
Et dans un environnement multi-utilisateur, tu risques en permanence des erreurs (entre le moment ou tu obtiens ton dmax et le
moment où tu l'utilises, un autre utilisateur a pu modifier la base et ton dmax n'est plus le bon dmax.

J-Pierre

Avatar
loutox
", "Table1") + 1" pour eviter ce genre de problemes ainsi que des trous dans
la numerotation.



Pourquoi les trous te gênent-ils ? Normalement, un numéroAuto est utilisé
de manière interne par l'appli et n'est jamais visible par l'utilisateur.

Virer le numéroAuto ? Quelle hérésie..... Ce n'est pas parce que tu as eu
un problème qu'il faut réagir comme ça.....


Hérésie... pas si ce Num auto fait des doublons, on peut alors douter de sa
fiabilité.


Et puis, les fonctions de domaine (dmax, dcount, etc) côté performance, ce
n'est pas le pied, il vaut mieux les éviter.
Et dans un environnement multi-utilisateur, tu risques en permanence des
erreurs (entre le moment ou tu obtiens ton dmax et le moment où tu
l'utilises, un autre utilisateur a pu modifier la base et ton dmax n'est
plus le bon dmax.


exact, mais on fait avec les moyens du bord, j'aimerais mieux avoir un num
auto fiable et ne pas faire ce bricolage.

J-Pierre


Le probleme n'est pas tant les trous , c'est que le numero auto insere des
doublons.
exemple : le maxi de la table est 3942 et le 3100 existe déja. Mais le
numero auto (qui est parti en live) veut affecter à nouveau 3100 sur un
nouvel enregistrement. avec un index sans doublons c'est génant.


Avatar
Bonjour,

"loutox" a écrit dans le message de news: 4492c052$0$4464$
Le probleme n'est pas tant les trous , c'est que le numero auto insere des doublons.
exemple : le maxi de la table est 3942 et le 3100 existe déja. Mais le numero auto (qui est parti en live) veut affecter à nouveau
3100 sur un nouvel enregistrement. avec un index sans doublons c'est génant.


sans entrer dans le débat de numéro auto à utilisation interne ou pas, le phénomène que tu énonces
évoque plutôt un début de corruption de ta base.

néanmoins, personnellement si je dois gérer des numéros de factures, je préfère gérer la numérotation moi-même et attribuer à ce
champ
la propriété clé primaire.


--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------

Avatar
J-Pierre
Un numéro de facture est une information publique, pas de trous, donc pas de numéros auto. Au deumeurant, pour être certain de ne
pas avoir de trous avec une gestion programmée des numéros de facture, il faut déjà bien connaître ADO, les BeginTrans et
CommitTrans. Pour le développeur moyen, finalement, un numéroAuto est plus sûr.

Autonum comme numéro interne ou pas ? Pour moi, il n'y a pas débat, si je veux une numérotation parfaite et sans trous, je le fais
moi-même...

Loutox, je répète que le fait que tu aies eu un problème ne doit pas signifier qu'il faut abandonner les numérosAuto.
Avais-tu défini ton NuméroAuto comme clé primaire ou comme index unique ? Ca n'évite pas les trous, mais ça évite les doublons :-)

J-Pierre

<Anor> a écrit dans le message de news: uK$
Bonjour,

"loutox" a écrit dans le message de news: 4492c052$0$4464$
Le probleme n'est pas tant les trous , c'est que le numero auto insere des doublons.
exemple : le maxi de la table est 3942 et le 3100 existe déja. Mais le numero auto (qui est parti en live) veut affecter à
nouveau 3100 sur un nouvel enregistrement. avec un index sans doublons c'est génant.


sans entrer dans le débat de numéro auto à utilisation interne ou pas, le phénomène que tu énonces
évoque plutôt un début de corruption de ta base.

néanmoins, personnellement si je dois gérer des numéros de factures, je préfère gérer la numérotation moi-même et attribuer à ce
champ
la propriété clé primaire.


--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------





Avatar
jean.paulo
Je ne veux pas entrer dans la polémique sur l'utilité du numéro auto, que
j'utilise
réguliérement sans que les trous me génent. Mais j'ai découvert un 'trou'
sérieux
dans la fiabilité. Si on utilise une requête 'Ajout' à partir par exemple
d'une copie
de la base, le numéro auto est REMIS à la valeur du dernier ajouté.

Et à partir de là, plus rien ne marche, car les nouveaux enregistrements
portent
des numéros existant. C'est une manoeuvre à éviter à tout prix !

--

Remove "bidon" to answer by mail
"
Avatar
J-Pierre
Bonjour,

Là tu m'intéresses, quand tu parles d'une copie de la base, tu veux sans doute dire de la table ?

Peux-tu publier ton code avec quelques infos sur la structure de la base (clés, index) et les circonstances exactes de l'exécution ?

J-Pierre

"jean.paulo" a écrit dans le message de news:
Je ne veux pas entrer dans la polémique sur l'utilité du numéro auto, que
j'utilise
réguliérement sans que les trous me génent. Mais j'ai découvert un 'trou'
sérieux
dans la fiabilité. Si on utilise une requête 'Ajout' à partir par exemple
d'une copie
de la base, le numéro auto est REMIS à la valeur du dernier ajouté.

Et à partir de là, plus rien ne marche, car les nouveaux enregistrements
portent
des numéros existant. C'est une manoeuvre à éviter à tout prix !

--

Remove "bidon" to answer by mail
"



Avatar
Salut

Il est rare d'avoir un numéro auto qui ne soit pas "indexé sans doublons".
Avec cette propriété sur le champ, l'ajout de doublons sera refusé

En revanche, une propriété de liste de valeurs "Limiter à Liste" n'est pas lue lors de l'exécution d'une requête ajout,
ce qui peut conduire un champ à contenir des valeurs non autorisées.

a+
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------

"jean.paulo" a écrit dans le message de news:
Je ne veux pas entrer dans la polémique sur l'utilité du numéro auto, que
j'utilise
réguliérement sans que les trous me génent. Mais j'ai découvert un 'trou'
sérieux
dans la fiabilité. Si on utilise une requête 'Ajout' à partir par exemple
d'une copie
de la base, le numéro auto est REMIS à la valeur du dernier ajouté.

Et à partir de là, plus rien ne marche, car les nouveaux enregistrements
portent
des numéros existant. C'est une manoeuvre à éviter à tout prix !

--

Remove "bidon" to answer by mail
"



Avatar
jean.paulo
En fait, c'est très simple. Je parle d'une copie complète de la base
(backup), ou d'une table
exportée vers une autre base. La table comporte une clé index principale
qui est le numéro
automatique.

Il n'y a pas de code. Ce que je voulais faire, c'était reconstituer quelques
entrées détruites par
erreur. J'ai donc 'lié' la table externe, puis juste créé une requête qui
filtrait les numéros
que je voulais integrer.

Soit par exemple une table avec 120000 records. Je voulais recréer les
records 25000 à
25010 (juste par exemple). Donc je crée la requête sélection, puis je la
modifie en requête
ajout de ma table originale....

Après cela, les nouveaux enregistrements de la table portaient les numéros
25011, 25012, etc... (et bien
entendu étaient refusés pour cause de doublons sur la clé principale)

En fait, cela pourrait servir pour remettre à zéro un numéro automatique.
Sinon, c'est assez
dangereux...

La réparation à consisté a refaire la même manoeuvre deux fois, pour
rajouter ainsi le vrai
'dernier' record de la table, après avoir completé la table en backup.

--

Remove "bidon" to answer by mail

"J-Pierre" a écrit dans le message de
news:
Bonjour,

Là tu m'intéresses, quand tu parles d'une copie de la base, tu veux sans
doute dire de la table ?


Peux-tu publier ton code avec quelques infos sur la structure de la base
(clés, index) et les circonstances exactes de l'exécution ?


J-Pierre

"jean.paulo" a écrit dans le message de news:


Je ne veux pas entrer dans la polémique sur l'utilité du numéro auto,
que


j'utilise
réguliérement sans que les trous me génent. Mais j'ai découvert un
'trou'


sérieux
dans la fiabilité. Si on utilise une requête 'Ajout' à partir par
exemple


d'une copie
de la base, le numéro auto est REMIS à la valeur du dernier ajouté.

Et à partir de là, plus rien ne marche, car les nouveaux enregistrements
portent
des numéros existant. C'est une manoeuvre à éviter à tout prix !

--

Remove "bidon" to answer by mail
"







Avatar
J-Pierre
Je ne pense pas qu'il s'agisse d'un bug, mais d'un comportement voulu d'Access.

Pas besoin de prendre une base et des tables liées, tu copies une table, puis tu fais une requête ajout qui insères les lignes de ta
copie dans la table.

Si tu spécifies explicitement le NuméroAuto dans les champs de ta requête, il est copié sans modification, par contre, si tu ne le
spécifie pas, une nouvelle valeur lui est attribuée.

Ce qui permet, si nécessaire, de récupérer tes lignes inchangées. C'est donc ta manière de faire ta requête en fonction de ce que tu
veux obtenir qui va déterminer le comportement d'Access.

J-Pierre

"jean.paulo" a écrit dans le message de news:
En fait, c'est très simple. Je parle d'une copie complète de la base
(backup), ou d'une table
exportée vers une autre base. La table comporte une clé index principale
qui est le numéro
automatique.

Il n'y a pas de code. Ce que je voulais faire, c'était reconstituer quelques
entrées détruites par
erreur. J'ai donc 'lié' la table externe, puis juste créé une requête qui
filtrait les numéros
que je voulais integrer.

Soit par exemple une table avec 120000 records. Je voulais recréer les
records 25000 à
25010 (juste par exemple). Donc je crée la requête sélection, puis je la
modifie en requête
ajout de ma table originale....

Après cela, les nouveaux enregistrements de la table portaient les numéros
25011, 25012, etc... (et bien
entendu étaient refusés pour cause de doublons sur la clé principale)

En fait, cela pourrait servir pour remettre à zéro un numéro automatique.
Sinon, c'est assez
dangereux...

La réparation à consisté a refaire la même manoeuvre deux fois, pour
rajouter ainsi le vrai
'dernier' record de la table, après avoir completé la table en backup.

--

Remove "bidon" to answer by mail

"J-Pierre" a écrit dans le message de
news:
Bonjour,

Là tu m'intéresses, quand tu parles d'une copie de la base, tu veux sans
doute dire de la table ?


Peux-tu publier ton code avec quelques infos sur la structure de la base
(clés, index) et les circonstances exactes de l'exécution ?


J-Pierre

"jean.paulo" a écrit dans le message de news:


Je ne veux pas entrer dans la polémique sur l'utilité du numéro auto,
que


j'utilise
réguliérement sans que les trous me génent. Mais j'ai découvert un
'trou'


sérieux
dans la fiabilité. Si on utilise une requête 'Ajout' à partir par
exemple


d'une copie
de la base, le numéro auto est REMIS à la valeur du dernier ajouté.

Et à partir de là, plus rien ne marche, car les nouveaux enregistrements
portent
des numéros existant. C'est une manoeuvre à éviter à tout prix !

--

Remove "bidon" to answer by mail
"










Avatar
J-Pierre
Le coup est parti un peu vite......

Comme le prochain NuméroAuto utilisé n'est pas modifié sauf si tu supprimes toutes les lignes de ta table puis que tu compresses ta
base, normalement, si tu veux réinsérer des lignes disparues depuis une copie, les "trous" sont là, et tu peux réimporter tes lignes
inchangées.

Si je comprends bien ton exemple, tu n'avais pas spécifié le NuméroAuto dans ta requête.
Mais alors, dans ce cas, pourquoi Access a-t-il choisi des NuméroAuto existants plutôt que d'assigner de nouveaux numéros ?

J-Pierre
1 2