 1 membre
Connectés : ( personne )
 - La Charte du Forum - Forum
 - Problèmes Access des débutants
 Sujet n° 418 |
Validation d'une saisie par rapport aux enregistrements de la même table |
le 08/11/2010 : 16:22
par kolele
visiteur
|
Salut 3Stones,
Nouvelles questions toujours sur le même projet de base de prêt de Manuel Scolaire, qui avance à grand pas, grâce à ton site pour 90% (à ce propos, merci pour tes explications sur les marges des Etats-étiquettes !)
Soit 3 tables :
T0_Elèves (contenant des élèves, clé primaire=CléElève)
T1_Inventaire (contenant les manuels scolaires, clé primaire = CléInventaire)
et T2_Attribution_des_manuels (contenant CléElève et CléInventaire en clés externe, DatePrêt et DateRetour).
Les élèves défilent à la bibliothèque du lycée à chaque rentrée des classes et à chaque sortie, pour prendre puis restituer les manuels mis à leur disposition.
Un élève peut avoir plusieurs manuels, un manuel peut successivement être prêté à plusieurs élèves, ce qui justifie la table T2_Attribution, avec les deux clés externes.
Un lecteur optique de code barre, via un formulaire, saisit la CléInventaire dans un nouvel enregistrement de la table T2_Attribution avec la date de prêt (en septembre) ; et un nouvel enregistrement en juin suivant, avec la DateRetour.
Au total, la table T2 a des enregistrements avec, tantôt des DatePrêt tantôt des DateRetour non null.
Deux soucis apparus au moment des tests :
a) un documentaliste peu attentionné peut scanner plusieurs fois le même ouvrage à un élève (plusieurs enregistrements dans T2_Attribution, avec le même N° en CléInventaire).
b) un élève mal intentionné peut rendre le manuel scolaire de la copine !
Pour le problème a) je voudrais, dès la saisie par le lecteur via le formulaire, repérer l'anomalie et bloquer la validation de l'enregistrement. Faire en sorte que le manuel n° 123 (CléInventaire) ne puisse être prêté une seconde fois.
Plus précisément : que le manuel n° 123 ne soit pas prêté plus de fois qu'il n'a été rendu. Dans la table T2_Attribution, pour la même valeur de CléInventaire et le même élève : (nombre d'enregistrements avec DatePrêt) < (nombre d'enregistrements avec DateRetour).
Je suppute que ça va emprunter la forme d'une instruction en boucle, qui compare le nouvel enregistrement à tous ceux précédemment existants dans la table mais je ne peux pas aller plus loin!
Merci pour ton éclairage. |
|  
|
Réponse n° 1
--------
le 08/11/2010 : 16:26
par kolele
visiteur
|
Désolé pour la mise en page du post précédent. Je viens de découvrir la prévisualisation sur le site ! |
|
|
|
Réponse n° 2
--------
le 10/11/2010 : 05:15
par 3Stone
Administrateur
|
Bonjour,
Pour le problème "a", un index (unique) composé des champs CleEleve et CleInventaire devrait suffire...
Pour "b", le numéro de chaque manuel devrait être unique, on saurait alors qui l'a emprenté.
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 3
--------
le 10/11/2010 : 14:30
par kolele
visiteur
|
Ça marche impec, pour le a). J'ai juste rajouté le champ
DatePrêt dans l'index (avec CléElève et CléInventaire) car dans la même table
il y a un enregistrement aller et un retour pour le même couple
ManuelScolaire-Elève (prêt puis retour). Ainsi, l'index bloque le même livre
prêté deux fois au même élève, le même jour, ce qui correspond exactement à la
situation d'un documentaliste trop rapide de la scan-douchette. Merci !
Question d'AccessCulture générale : ça fait 10 ans que
j'utilise Access et j'ai pu me passer de la fonction Index. Les recherches sur
mes bases ne sont pas lentes pour autant.
Quand faut-il y recourir (en dehors d'un besoin précis,
comme précédemment) ? Faut-il y songer dès la conception d'une base ? Y a t-il
des inconvénients à les multiplier (ça ralentirait la base, lit-on).
Par ailleurs, j'ai découvert dans mes tables plein d'index
créés automatiquement.
Enfin, en réseau, la création d'index peut-elle résoudre mes
problèmes dans l'exécution des objets ? |
|
|
|
Réponse n° 4
--------
le 10/11/2010 : 15:26
par 3Stone
Administrateur
|
Bonjour,
L'absence ou le manque d'un index est moins pénalisant lorsque la base est "locale". Donc lorsque l'application et les tables sont sur le PC de l'utilisateur.
Il en va tout autrement lorsque l'on travaille en réseau avec une base scindée en frontale/dorsale. Les tables se trouvant alors sur un serveur distant quelque part sur le réseau.
L'absence d'index peut alors avoir un effet dramatique sur les performances.
Si l'on prend l'exemple d'un champ "NomEleves" dans lequel on souhaite rechercher les Durand ou Durant. La recherche ressemblera alors à ceci "Duran*".
Pour trouver cela, Access sera obliger de traverser toute la table et de scruter le champ, enregistrement par enregistrement et cela, après avoir rapatrié toute la table.
Par contre, si l'on à pris soin de créer un index sur ce champ, la réponse sera quasiment instantanée. La longueur d'un index n'ayant quasiment pas d'influence sur le temps de réponse. Même 100.000 items dans un index n'occupe Access qu'une fraction de seconde... De plus, l'index sera probablement déjà disponible en local.
Ceci dit, il ne faut pas indexer tout et n'importe quoi, car comme tu le soulignes, ces index doivent être maintenu par Access et cela à chaque enregistrement ou modification dont ils font partie.
En général, on limite donc l'indexation au champs qui sont fréquemment utilisés dans les recherches et dans les tris. Les clés étant indexées par défaut.
Cordialement,
Pierre(3stone)
PS: Ecris ton message directement avec l'éditeur inclus ici, pour éviter ces messages illisibles |
|
|
|
Réponse n° 5
--------
le 12/11/2010 : 19:42
par kolele
visiteur
|
Je note tout ça précieusement. Ce doit être une des raisons de mes échecs à passer en réseau (avec les requêtes de fainéant, une seule pour 25 états ou formules, et qui font descendre tous les champs des tables sources. Un jour, je ferais un bêtisier de tout ce qui ne faut pas faire pour je jamais réussir la scission des objets.
Merci encore, 3Stone.
Respect pour tout ce que tu fais. |
|
|
|
 sujet actif
sujet clos
 Important!
 Nouveau message -
 Rectifier message
 Clôturer sujet
 Remonter
|
© 2004-2013 
