Message d'erreur doublons, mais je ne sais faire autrement...

Salut,

"Loïc V."
| J'ai une table: Bordereau
| Un autre: n°d'articles
|
| Il me faut d'abord définir le bordereau en précisant la date, le client,
| ect... J'ai donc créé un formulaire adéquat.
|
| J'ai également créé un autre formulaire pour l'encodage des articles
| (description, ect..). Ces données affectent les enregistrements de la table,
| c'est voulu.
|
| Par contre, j'aimerais lier ces deux formulaires pour que lorsque j'établi
| un bordereau, j'ai la possiblité d'ouvrir un sous-formulaire (continu) qui me
| permet d'encoder les N°articles à mentionner sur ce bordereau.
|
| J'y arrive, le seul problème, c'est que dans toutes mes tentatives, lorsque
| j'inscris le N°article, il me dit qu'il y a un doublon (normal, vu que je
| l'ai précisé de la sorte dans la table ad'hoc). Par contre, si j'inscris une
| donnée au hasard, je la retrouve enregistrée dans ma table N°Articles.
|
| Comment est-ce que je peux faire pour que ce sous-formulaire me permette
| d'insérer des enregistristrements:
|
| - sans qu'il aille me dire qu'il y a un doublon
| - sans modifier ma table N°Articles
|
| autrement dit, j'aimerais que dans ce formulaire, je puisse insérer des
| données qui sont reprises dans la table n°Articles sans affecter les données
| de la table.


Je ne vois pas clairement ce que tu as fait, mais tu devrais avoir qque
chose comme ceci:

Ta table tblBordereau
- avec comme clé primaire le NoBordereau
- CodeClient
- etc...

Une table tblBordereauDetails
- LigneDetail - clé primaire en numauto
- NoBordereau - clé externe, indexé avec doublons
- CodeArticle
- etc...

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Salut 3stone! (et merci de te pencher sur mon cas)

Les deux tables que tu mentionnes, oui, j'ai truc du genre.

J'aimerais avoir un formulaire avec "par Bordereau, j'ai x articles"
(attention, les articles, il s'agit de plaquettes numérotées, donc il ne peut
en avoir deux du même numéro).

J'ai donc une table avec toute une série de numéro de plaquettes et une
autre table avec des numéros de bordereau.

A présent, j'aimerais créer ce formulaire qui va permettre d'encoder ces
fichues plaquettes dans mon bordereau.

Or, lorsque je le fais, la structure paraît correcte mais manifestement pas
le fond. en effet, lorsque je tape une valeur de plaquette (existante dans la
table "plaquette), il me dit qu'il y a doublon. Cela me paraît normal, vu
qu'il fait alors un enregistrement dans la table plaquette et il remarque que
le numéro de plaquette existe déjà (vu que indexé-sans doublon).

Qu'est ce que je dois changer dans la forme pour que ce formulaire ne me
prenne que le numéro de plaquette, qu'il va gentillement l'enregistrer dans
la table bordereau (en cascade, n°bordereau + n°plaquette) sans qu'il vienne
m'emmerder à modifier ma table plaquette ?

J'ai essayé par la méthode des Màj, via une requête, via une une autre table
qu sert d'intermédiaire, ect..., mais à chaque fois, j'ai ce foutu message de
doublon.

Il y a un truc qui m'échape. tu as une idée de quoi ?

Bien à toi,

Loïc



"3stone" a écrit :

Salut,

"Loïc V."
| J'ai une table: Bordereau
| Un autre: n°d'articles
|
| Il me faut d'abord définir le bordereau en précisant la date, le client,
| ect... J'ai donc créé un formulaire adéquat.
|
| J'ai également créé un autre formulaire pour l'encodage des articles
| (description, ect..). Ces données affectent les enregistrements de la table,
| c'est voulu.
|
| Par contre, j'aimerais lier ces deux formulaires pour que lorsque j'établi
| un bordereau, j'ai la possiblité d'ouvrir un sous-formulaire (continu) qui me
| permet d'encoder les N°articles à mentionner sur ce bordereau.
|
| J'y arrive, le seul problème, c'est que dans toutes mes tentatives, lorsque
| j'inscris le N°article, il me dit qu'il y a un doublon (normal, vu que je
| l'ai précisé de la sorte dans la table ad'hoc). Par contre, si j'inscris une
| donnée au hasard, je la retrouve enregistrée dans ma table N°Articles.
|
| Comment est-ce que je peux faire pour que ce sous-formulaire me permette
| d'insérer des enregistristrements:
|
| - sans qu'il aille me dire qu'il y a un doublon
| - sans modifier ma table N°Articles
|
| autrement dit, j'aimerais que dans ce formulaire, je puisse insérer des
| données qui sont reprises dans la table n°Articles sans affecter les données
| de la table.


Je ne vois pas clairement ce que tu as fait, mais tu devrais avoir qque
chose comme ceci:

Ta table tblBordereau
- avec comme clé primaire le NoBordereau
- CodeClient
- etc...

Une table tblBordereauDetails
- LigneDetail - clé primaire en numauto
- NoBordereau - clé externe, indexé avec doublons
- CodeArticle
- etc...

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Yessssssssssssssssssssssssssssssss!
J'ai trouvé, ouf!!!!

J'ai essayé sur ue base vierge. J'ai créé 3 tables:
1) Bordereau (N°Bordereau)
2) Plaquette A (Dont les Numéros de plaquettes pointent vers [Plaquette B]
par un menu déroulant
3) Plaquette B (qui reprend tout ce dont j'ai besoin sur la plaquette)

Je crée un formulaire reprenant les trois tables (avec les clefs externes
pour faire les liens), et hop!, il ne me mets plus de doublons.

Chic, alors!

Mas j'ai encore de quoi m'énerver (Lol!)

Au fait, ça veut dire quoi 'indexé" ?


Merci beaucoup,

Loïc

Salut,

"Loïc V."
|
| Yessssssssssssssssssssssssssssssss!
| J'ai trouvé, ouf!!!!


;-))


|
| Au fait, ça veut dire quoi 'indexé" ?


Regarde dans la table, dans la propriété des champs, et spécialement
pour la clé primaire ou clé externe, champs de recherche etc...
A connaître *absolument* dès que l'on cherche sérieusement à créer
une base qui contient un peu plus que les tantes ou cousins germains...

:-)

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Salut 3Stone!

Oui, je sais où cela se trouve, mais je sais pas trop bien à quoi ca sert.
Je sais juste que la clé primaire doit être indexée.
J'avue y aller avec le feeling. si la donnée est importante, je l'indexe, si
elle ne sert que d'intermédiaire, je ne l'indexe pas.
Mais tu as raison, je vais aller voir de plus près ce que ca veut dire.

Merci.

Loïc





"3stone" a écrit :

Salut,

"Loïc V."
|
| Yessssssssssssssssssssssssssssssss!
| J'ai trouvé, ouf!!!!


;-))


|
| Au fait, ça veut dire quoi 'indexé" ?


Regarde dans la table, dans la propriété des champs, et spécialement
pour la clé primaire ou clé externe, champs de recherche etc...
A connaître *absolument* dès que l'on cherche sérieusement à créer
une base qui contient un peu plus que les tantes ou cousins germains...

:-)

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Salut,

"Loïc V."
| mais je sais pas trop bien à quoi ca sert.
| Je sais juste que la clé primaire doit être indexée.
| J'avue y aller avec le feeling. si la donnée est importante, je l'indexe, si
| elle ne sert que d'intermédiaire, je ne l'indexe pas.

Les champs indexés sont gérés à part par Access.
Chaque index est repris dans une liste avec une référence à l'enregistrement
dont provient le champ.

Un exemple simple:
Si tu fait une recherche sur le nom d'une personne (LastName) et que ce champ
n'est pas indexé, Access charge toute la table et parcourt toute la "colonne"
LastName pour retrouver ce que tu cherches...
Si par contre ce champ est indexé, Access charge uniquement cet index,
cherche dans cette liste (qui est déjà triée) et récupère le pointeur qui
désigne l'enregistrement.

Les constatations d'un gros ralentissement lorsque la base est utilisée
en réseau vient souvent (mais pas exclusivenemt) de ce genre d'erreur.
Cela, parce que en local, Access à tout "sous la main" et les erreurs
de conception ne sont pas aussi pénalisante.

Ceci ne signifie pas qu'il faut tout simplement indexer tous les champs.
Car, le maintient d'un index consomme de la place et... du temps.
Si un champ est utiliser couramment pour les recherches ou les tris, il est
bon d'en prévoir l'indexation.

Quelques essais sur une base conséquente et sur un réseau quelque
peu encombré montre cela de façon flagrante.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Ha! j'avais été voir sur le net, y a pas beaucoup d'infos si ce n'est que
cela accélère les recherches.

Merci pour tes explications.

Tu dis que cela ralentis très fort la base de données une fois qu'elle est
en réseau.
au fait, c'est compliqué de mettre toute une base données sur le web ?
(j'veux dire par là, uniquement les formulaires, les tables restent sur le
serveur). On sait tout transférer sans manipulation ou il faut refaire tous
les formulaires ?

j'ai vu qu'il y avait des programmes pour cela (autour de 40 euro). Ils font
vraiment tout tout seul ou il faut s'y connaître pour manipuler ce genre de
logiciel ?

(C'est une question hors-sujet, et pas d'actualité, réponds juste si tu
passes par là==> Genre: oui, c'est méga super compliqué, contente toi de
faire des petites bases gentilles avc Mickey et Donald...hahahaha).

alleiiiiiiii,

Merci beaucoup pour ton aide, j'ai déjà beaucoup appris grâce à toi.

Loïc




"3stone" a écrit :

Salut,

"Loïc V."
| mais je sais pas trop bien à quoi ca sert.
| Je sais juste que la clé primaire doit être indexée.
| J'avue y aller avec le feeling. si la donnée est importante, je l'indexe, si
| elle ne sert que d'intermédiaire, je ne l'indexe pas.

Les champs indexés sont gérés à part par Access.
Chaque index est repris dans une liste avec une référence à l'enregistrement
dont provient le champ.

Un exemple simple:
Si tu fait une recherche sur le nom d'une personne (LastName) et que ce champ
n'est pas indexé, Access charge toute la table et parcourt toute la "colonne"
LastName pour retrouver ce que tu cherches...
Si par contre ce champ est indexé, Access charge uniquement cet index,
cherche dans cette liste (qui est déjà triée) et récupère le pointeur qui
désigne l'enregistrement.

Les constatations d'un gros ralentissement lorsque la base est utilisée
en réseau vient souvent (mais pas exclusivenemt) de ce genre d'erreur.
Cela, parce que en local, Access à tout "sous la main" et les erreurs
de conception ne sont pas aussi pénalisante.

Ceci ne signifie pas qu'il faut tout simplement indexer tous les champs.
Car, le maintient d'un index consomme de la place et... du temps.
Si un champ est utiliser couramment pour les recherches ou les tris, il est
bon d'en prévoir l'indexation.

Quelques essais sur une base conséquente et sur un réseau quelque
peu encombré montre cela de façon flagrante.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Salut,

"Loïc V."
| Tu dis que cela ralentis très fort la base de données une fois qu'elle est
| en réseau.

Heu... non, je ne pense pas avoir écrit cela ainsi ;-)

Pour simplifier:
Une base mal faite peut fonctionner de façon satisfaisant en local,
mais devenir un véritable escargot en réseau.

Mal faite: pas d'index, des requery à tour de bras, mauvaises tables,
mauvaises relations, formulaires à multiple source, liste déroulante
mal faite, source des formulaires mal pensés, etc etc... ;-)



| au fait, c'est compliqué de mettre toute une base données sur le web ?
| (j'veux dire par là, uniquement les formulaires, les tables restent sur le
| serveur). On sait tout transférer sans manipulation ou il faut refaire tous
| les formulaires ?
|
| j'ai vu qu'il y avait des programmes pour cela (autour de 40 euro). Ils font
| vraiment tout tout seul ou il faut s'y connaître pour manipuler ce genre de
| logiciel ?

Access n'a jamais été dans son élément lorsqu'il sagit du Web, même
si cela reste possible;

Ce n'est pas pour rien que la quasi totalité sur le net sont basée sur
MySql, Sql Server et autres...

De toute façon, tes formulaires actuels - ceux que tu utilises en local
ne conviennent pas.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)