Bonjour à tous
grace aux conseils glanés ici (c'est le meilleur ng que je connaisse)
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.
Bonjour à tous
grace aux conseils glanés ici (c'est le meilleur ng que je connaisse)
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.
Bonjour à tous
grace aux conseils glanés ici (c'est le meilleur ng que je connaisse)
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
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
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
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.
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.
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.
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
---------------------------------------------
Bonjour,
"loutox" <loutox@spammedoncailleurs.fr> a écrit dans le message de news: 4492c052$0$4464$636a55ce@news.free.fr...
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
---------------------------------------------
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
---------------------------------------------
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
"
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 !
--
Jean.paulo.bidon@free.fr
Remove "bidon" to answer by mail
"
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
"
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
"
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 !
--
Jean.paulo.bidon@free.fr
Remove "bidon" to answer by mail
"
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
"
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
"
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" <Jean.paulo.bidon@free.fr> a écrit dans le message de news:
ujg1sfckGHA.2200@TK2MSFTNGP05.phx.gbl...
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 !
--
Jean.paulo.bidon@free.fr
Remove "bidon" to answer by mail
"
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
"
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,
quej'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
exempled'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
"
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.
--
Jean.paulo.bidon@free.fr
Remove "bidon" to answer by mail
"J-Pierre" <pas.de.pub.jpberchtold@hotmail.com> a écrit dans le message de
news:uFHVffdkGHA.3816@TK2MSFTNGP02.phx.gbl...
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" <Jean.paulo.bidon@free.fr> a écrit dans le message de news:
ujg1sfckGHA.2200@TK2MSFTNGP05.phx.gbl...
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 !
--
Jean.paulo.bidon@free.fr
Remove "bidon" to answer by mail
"
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,
quej'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
exempled'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
"