créer deux bases test1.mdb, test2.mdb puis créer dans test1 et test2 deux
tables de même structure
idx : type numeroAuto primary Key
Field1 : type text
Dans test1 la table s'appelle testindex1: on ajoute 10 lignes puis on
supprime les lignes 3,4,5,6,7: il reste les lignes 1,2,8,9,10
dans test2 la table s'appelle testindex2: on ajoute 4 lignes et on efface
1,2,3: il reste la ligne 4
dans la base test2 on attache la table indextest1 de la base test1
et dans cette base test2 on execute la requete
INSERT INTO indextest1 SELECT indextest2 .* FROM indextest2;
si on ouvre la table indextest1 on trouve bien les valeurs 1,2,4,8,9,10 ce
qui est correct, mais si on essaie de créer une nouvelle ligne, la valeur du
champ idx sera 5 et non pas 11. Résultat on ne peut plus ajouter que 2 lignes
dans cette table (6 et 7) ensuite Access considère que la ligne créée est en
doublon et ne veut plus rien faire. La table est corrompue et un compactage
ne change rien au probleme: il faut recréer une table vide, et y retransferer
les données.
Ca doit être ce qu'on appelle un petit bug chez MS ;-)
Ceci ne se produit pas si indextest1 n'est pas une table attachée.
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.paulo
Oui, c'est un truc connu, si on fait une importation ou une requète 'ajout', l'index auto se met a la dernière valeur ajoutée. Pour éviter le problème, le plus simple est de créer un record plus grand que le dernier de chaque table avant d'executer. (ou de faire d'abord le transfert vers la table la plus courte)
-- Jean.paulo
"dr.tom" a écrit dans le message de news:
exemple: access2002 (SP3 - 10.6501.6735)
créer deux bases test1.mdb, test2.mdb puis créer dans test1 et test2 deux tables de même structure idx : type numeroAuto primary Key Field1 : type text
Dans test1 la table s'appelle testindex1: on ajoute 10 lignes puis on supprime les lignes 3,4,5,6,7: il reste les lignes 1,2,8,9,10 dans test2 la table s'appelle testindex2: on ajoute 4 lignes et on efface 1,2,3: il reste la ligne 4
dans la base test2 on attache la table indextest1 de la base test1 et dans cette base test2 on execute la requete INSERT INTO indextest1 SELECT indextest2 .* FROM indextest2;
si on ouvre la table indextest1 on trouve bien les valeurs 1,2,4,8,9,10 ce qui est correct, mais si on essaie de créer une nouvelle ligne, la valeur du
champ idx sera 5 et non pas 11. Résultat on ne peut plus ajouter que 2 lignes
dans cette table (6 et 7) ensuite Access considère que la ligne créée est en
doublon et ne veut plus rien faire. La table est corrompue et un compactage
ne change rien au probleme: il faut recréer une table vide, et y retransferer
les données.
Ca doit être ce qu'on appelle un petit bug chez MS ;-)
Ceci ne se produit pas si indextest1 n'est pas une table attachée.
Oui, c'est un truc connu, si on fait une importation ou une requète 'ajout',
l'index auto se met
a la dernière valeur ajoutée. Pour éviter le problème, le plus simple est de
créer un record
plus grand que le dernier de chaque table avant d'executer. (ou de faire
d'abord le transfert
vers la table la plus courte)
--
Jean.paulo
"dr.tom" <dr.tom@discussions.microsoft.com> a écrit dans le message de
news:1C164C20-0611-47A9-8623-25C06D747835@microsoft.com...
exemple: access2002 (SP3 - 10.6501.6735)
créer deux bases test1.mdb, test2.mdb puis créer dans test1 et test2 deux
tables de même structure
idx : type numeroAuto primary Key
Field1 : type text
Dans test1 la table s'appelle testindex1: on ajoute 10 lignes puis on
supprime les lignes 3,4,5,6,7: il reste les lignes 1,2,8,9,10
dans test2 la table s'appelle testindex2: on ajoute 4 lignes et on efface
1,2,3: il reste la ligne 4
dans la base test2 on attache la table indextest1 de la base test1
et dans cette base test2 on execute la requete
INSERT INTO indextest1 SELECT indextest2 .* FROM indextest2;
si on ouvre la table indextest1 on trouve bien les valeurs 1,2,4,8,9,10 ce
qui est correct, mais si on essaie de créer une nouvelle ligne, la valeur
du
champ idx sera 5 et non pas 11. Résultat on ne peut plus ajouter que 2
lignes
dans cette table (6 et 7) ensuite Access considère que la ligne créée est
en
doublon et ne veut plus rien faire. La table est corrompue et un
compactage
ne change rien au probleme: il faut recréer une table vide, et y
retransferer
les données.
Ca doit être ce qu'on appelle un petit bug chez MS ;-)
Ceci ne se produit pas si indextest1 n'est pas une table attachée.
Oui, c'est un truc connu, si on fait une importation ou une requète 'ajout', l'index auto se met a la dernière valeur ajoutée. Pour éviter le problème, le plus simple est de créer un record plus grand que le dernier de chaque table avant d'executer. (ou de faire d'abord le transfert vers la table la plus courte)
-- Jean.paulo
"dr.tom" a écrit dans le message de news:
exemple: access2002 (SP3 - 10.6501.6735)
créer deux bases test1.mdb, test2.mdb puis créer dans test1 et test2 deux tables de même structure idx : type numeroAuto primary Key Field1 : type text
Dans test1 la table s'appelle testindex1: on ajoute 10 lignes puis on supprime les lignes 3,4,5,6,7: il reste les lignes 1,2,8,9,10 dans test2 la table s'appelle testindex2: on ajoute 4 lignes et on efface 1,2,3: il reste la ligne 4
dans la base test2 on attache la table indextest1 de la base test1 et dans cette base test2 on execute la requete INSERT INTO indextest1 SELECT indextest2 .* FROM indextest2;
si on ouvre la table indextest1 on trouve bien les valeurs 1,2,4,8,9,10 ce qui est correct, mais si on essaie de créer une nouvelle ligne, la valeur du
champ idx sera 5 et non pas 11. Résultat on ne peut plus ajouter que 2 lignes
dans cette table (6 et 7) ensuite Access considère que la ligne créée est en
doublon et ne veut plus rien faire. La table est corrompue et un compactage
ne change rien au probleme: il faut recréer une table vide, et y retransferer
les données.
Ca doit être ce qu'on appelle un petit bug chez MS ;-)
Ceci ne se produit pas si indextest1 n'est pas une table attachée.
