sifflet_
Messages postés70Date d'inscriptionmardi 25 juillet 2006StatutMembreDernière intervention 2 mai 2007
-
2 mai 2007 à 09:51
sifflet_
Messages postés70Date d'inscriptionmardi 25 juillet 2006StatutMembreDernière intervention 2 mai 2007
-
2 mai 2007 à 15:54
Salut tout le monde!
Je m'occupe d'une base de donéées qui permet de gérer
les adresses de membres d'une association sportive. Dans cette base, chaque personne possède un numéro de membre
qui est un numéro auto dans ma table Access (c'est aussi la clé
primaire de la table). Les problèmes interviennent dès que je supprime
et recréé des membres.
En effet, en supprimant les membres, forcément il y a des "trous" qui
se créent dans la liste des numéros auto. Ensuite, quand je recréé un
membre: au lieu de prendre le tout dernier numéro +1, dans certains cas
(et pas tout le temps !) il remplit un trou et réattribue un numéro de
membre qui a été supprimé.
Dans le fond ça me pose pas vraiment de problèmes, si ce n'est pour
l'archivage, mais c'est du détail.... Non, les soucis viennent plutôt
quand je créé le membre suivant et qu'Access attribue prend le dernier
numéro qu'il vient d'atribuer +1. Cela arrive qu'il donne un numéro
existe déjà => plantage pour violation de clé lors de l'Update.
Je sais pas si c'est clair, pour le coup je vous mets un exemple:
Une liste de numéros de membres pour 2006:
1234
1235
1236 (n'a pas payé sa coti et se trouve supprimé en 2007)
1237
Liste 2007:
1234
1235
1237
On va ajouter 2 nouveaux membres pour 2008:
1234
1235
1236 (Avec du bol c'est ok)
1237 (violation de clé...)
1237
Le souci, c'est que tout est fait par des formulaires et la base (de
6800 membres tout de même) est gérée par des secrétaires qui n'ont pas
accès au différentes tables. Parfois, il faut recommencer 3-4 fois la
saisie complète des données de la personne jusqu'à ce que ça marche...
J'ai déjà essayé d'exporter la table dans un fichier Excel et de la
ré-importer (j'ai vu ça en recherchant "numéro automatique" ici), mais
ça ne change rien... Dommage!
chaibat05
Messages postés1883Date d'inscriptionsamedi 1 avril 2006StatutMembreDernière intervention20 novembre 20072 2 mai 2007 à 10:37
Bonjour, effectivement Exploreur, c' est bizzare
qu' un N° Auto puisse être choisi (pour boucher les trous).
Toujours est-il qu' en observant l' exemple, il y' a peut être
un début d' explication :
1234
1235
1236 (n'a pas payé sa coti et se trouve supprimé en 2007)
1237
Liste 2007:
1234
1235
1237
On va ajouter 2 nouveaux membres pour 2008:
1234
1235
1236 'c' est ce N° qui est considéré comme le dernier
1237
1237
1236 étant le dernier à être ajouté selon la logique du
"combler les trous" , le prochain est, de ce fait, 1237.
Or 1237 éxiste déjà =>plantage
Regarde au niveau du code comment est géré l' ajout.
Si c' est avec Last remplaces le par Max
cs_Nicko11
Messages postés1141Date d'inscriptionmercredi 7 mars 2007StatutMembreDernière intervention19 septembre 20073 2 mai 2007 à 10:38
En effet, je suis d'accord et j'ai pu le vérifier par moi-meme, lorsque tu as un eclé primaire sans doublons et numéro auto, le numéro attribué est le dernier qui a été enregistré (meme s'il a été ensuite effacé) +1. Il ne remplit donc pas les trous.
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 2 mai 2007 à 10:57
Il n'y a pas de mystères, si le champ est la clé primaire, qu'il est déclaré comme n°auto sans doublon, alors Access ne doit normalement pas réutilisé le n°, même si celui-ci a été supprimer.
Access ne pourra réutiliser le n° que s'il y a eu recompactage ou réparation de la base.
Attention, certains programmeur fonct systématiquement un recompactage de la base à la fermeture soit de la base soit du logiciel. C'est très pratique pour économiser l'esace disque et avoir une base légère, seulement on pert toutes les références des doublons, etc..... Et donc on perd par le même coup toute la gestion des clés primaires que l'on a mis en place en jouant sur ces options.
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 2 mai 2007 à 11:24
si c'est le seul qui manque après compactage, il sera considéré comme premier libre et donc comme dernier utilisé dès qu'un enregistrement est ajouter.
Ensuite qu'il parte sur le 1237 alors que celui-ci n'est pas libre est un peu bizare. Est-ce du au fait que ce soit un n° auto ???
Mais je ne me rapelle pas avoir eu ce problème normalement il devrait aler chercher le premier libre.
---- Sevyc64 (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #
chaibat05
Messages postés1883Date d'inscriptionsamedi 1 avril 2006StatutMembreDernière intervention20 novembre 20072 2 mai 2007 à 11:30
à mon avis pour les tables indéxées sur un N° Auto, il utilise un fichier index
sur le quel est reporté le N° du dernier ajouter, vu que selon la logique du
N° Auto, le dernier ajouté est forcément le dernier de la table.
jmfmarques
Messages postés7666Date d'inscriptionsamedi 5 novembre 2005StatutMembreDernière intervention22 août 201427 2 mai 2007 à 11:33
Bonjour à tous,
Sifflet devrait nous montrer ici les lignes (et celles-là uniquement) de code utilisées pour les ajouts d'articles dans sa base.
La lecture de ces lignes devrait être normalement révélatrice de ce que ce qu'il appelle numérotation automatique est une numérotation/Access ou une numérotation dont l' "automatisme" est finalement "géré" par l'appli (ce qui n'est pas la même chose du tout)
cs_Exploreur
Messages postés4821Date d'inscriptionlundi 11 novembre 2002StatutMembreDernière intervention15 novembre 201615 2 mai 2007 à 11:35
Bonjou à tous,
sifflet_ , moi il y a un truc qui lme chagrine, pour ne plus avoir ton problème, tu peux faire comme le dit Casy, un compactage et une réparation de ta base...Des codes il y en à sur le site..
Mais je trouve bizarre, du moins génant, d'utiliser le clé primaire de ta table pour réferencer un membre...Le mieux je pense(c'est mon avis et n'engage que moi), c'est de créer un champ prévu à cet éffet pour donner un numéro de réferencement de membres..Après libre à toi de gérer les numéro effacés ou pas...
sifflet_
Messages postés70Date d'inscriptionmardi 25 juillet 2006StatutMembreDernière intervention 2 mai 2007 2 mai 2007 à 11:44
Salut c't'équipe!
Merci pour vos réponses, effectivement, il y a un compactage de la DB
lors de la fermeture, honnêtement je ne vois que ça, car parfois ça
marche très bien et à d'autres moments ça ne joue plus. Voici le code
pour l'ajout d'un membre:
Sub intro()
'Introduction des nouveaux membres FVJC
Dim mabd As Database, matable As Recordset
Set mabd = DBEngine.Workspaces(0).Databases(0)
Set matable = mabd.OpenRecordset("Membres_FVJC", dbOpenDynaset)
PS: désolé pour les accents dans les champs, mais je ne suis que le
modifieur de code et pas le créateur... Quoi qu'il en soit, normalement
ça fonctionne...
chaibat05
Messages postés1883Date d'inscriptionsamedi 1 avril 2006StatutMembreDernière intervention20 novembre 20072 2 mai 2007 à 12:14
ça confirme ce que je disais..
c' est le matable.MoveLast qui pose problème.
Ce que je voulais dire dans mon dernier post
c' est qu' il arrive parfois que l'e fichier Index
soit endommagé.
Théoriquement, avec le N° Auto, ça devrait marcher
sans le MoveLast
sifflet_
Messages postés70Date d'inscriptionmardi 25 juillet 2006StatutMembreDernière intervention 2 mai 2007 2 mai 2007 à 12:52
Non, j'ai un champ "no_membre" dans ma table "membres_FVJC" qui contient le numéro auto et qui est la clé primaire.
Si tu veux mon association est en fait une fédération et plusieurs
membres peuvent être de la même société et donc ont le même numéro de
société. Les sociétés sont dans une autre table.
Pour le MoveLast, je sais pas vraiment pourquoi il y a if matable.BOF ?
A mon avis quand tu fais un AddNew, il se trouve de toute manière en bas de la table.
chaibat05
Messages postés1883Date d'inscriptionsamedi 1 avril 2006StatutMembreDernière intervention20 novembre 20072 2 mai 2007 à 13:09
oui t' as raison pour le AddNew.
Pour le MoveLast on le fait généralement,
mais pas dans ton cas,pour récupérer le dernier numéro
et l' incrémenter de 1.
Dans le N° Auto, si tu le force à se positionner sur le dernier
et que, pour des raisons qu' on cherche toujours à comprendre,
le dernier n' est pas le dernier de la table, alors il y' a problème.
Je persiste à croire que lors d' un empacktage, l' opération s' est mal
terminée.
sifflet_
Messages postés70Date d'inscriptionmardi 25 juillet 2006StatutMembreDernière intervention 2 mai 2007 2 mai 2007 à 13:18
C'est fort probable... Mais alors quel serait le remède ?
Comme je l'ai déjà dit, j'ai déjà essayé exporter ma table vers Excel,
recréé une autre table avec les mêmes champs et importé mes données
dedans, mais c'est toujours pareil....
En tout cas, merci à vous de vous intéresser à mes problèmes et de me
répondre aussi promptement: c'est très plaisant, alors bravo à vous et
à votre dévouement pour la communauté !
chaibat05
Messages postés1883Date d'inscriptionsamedi 1 avril 2006StatutMembreDernière intervention20 novembre 20072 2 mai 2007 à 15:03
de retour,
pour le remède, il y' a peut être une solution à ça,
d' ailleurs ça été prévu par Access. puisque la fonction
"Réparer une base de données" est integrée au module
Utilitaires de base de données (juste au dessus de compacter...)
Essayes de voir avec ça .
Je pourrais aussi te conseiller de ne pas utiliser de N° Auto, mais je
sais que parfois on hérite des choses dont on est pas responsable.
Bonne continuation ...
PS: Merci d' avoir compris Compactage au lieu d' empacktage ...