Bonjour / Bonsoir
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Table UN Liste des individus avec No automatique, Champs NoAuto et
Champs NOM
Table deux avec les champs suivants
PropriétéNo, Proprio1, Proprio2, Proprio3
avec Relation un (NOM) à plusieurs les trois champs Proprio
Est-ce possible, ou puis-je trouver un exemple?
Merci de votre aide
Bonjour / Bonsoir
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Table UN Liste des individus avec No automatique, Champs NoAuto et
Champs NOM
Table deux avec les champs suivants
PropriétéNo, Proprio1, Proprio2, Proprio3
avec Relation un (NOM) à plusieurs les trois champs Proprio
Est-ce possible, ou puis-je trouver un exemple?
Merci de votre aide
Bonjour / Bonsoir
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Table UN Liste des individus avec No automatique, Champs NoAuto et
Champs NOM
Table deux avec les champs suivants
PropriétéNo, Proprio1, Proprio2, Proprio3
avec Relation un (NOM) à plusieurs les trois champs Proprio
Est-ce possible, ou puis-je trouver un exemple?
Merci de votre aide
Salut,
Albert wrote:Bonjour / Bonsoir
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Table UN Liste des individus avec No automatique, Champs NoAuto et
Champs NOM
Table deux avec les champs suivants
PropriétéNo, Proprio1, Proprio2, Proprio3
avec Relation un (NOM) à plusieurs les trois champs Proprio
Est-ce possible, ou puis-je trouver un exemple?
Merci de votre aide
Ne surtout pas faire cela !!!
Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?
En fait, il faut au minimum 3 tables:
T_Propriétés
-------------
# ID_Propriété
- Nom_Propriete
- ...
T_Popriétaires
----------
# ID_Proprio
- Nom_Proprio
- adresse
-
T_Popriétés_Poprios
--------------------
* ID_Propriété
* ID_Propriétaire
Cela permet d'avoir Nx propriétaires pour une propriété et
Nx popriétés pour un même propriétaire.
Autrement dit, une relation plusieurs à plusieurs entre la table
T_Propriétés et T_Propriétaires
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
Albert wrote:
Bonjour / Bonsoir
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Table UN Liste des individus avec No automatique, Champs NoAuto et
Champs NOM
Table deux avec les champs suivants
PropriétéNo, Proprio1, Proprio2, Proprio3
avec Relation un (NOM) à plusieurs les trois champs Proprio
Est-ce possible, ou puis-je trouver un exemple?
Merci de votre aide
Ne surtout pas faire cela !!!
Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?
En fait, il faut au minimum 3 tables:
T_Propriétés
-------------
# ID_Propriété
- Nom_Propriete
- ...
T_Popriétaires
----------
# ID_Proprio
- Nom_Proprio
- adresse
-
T_Popriétés_Poprios
--------------------
* ID_Propriété
* ID_Propriétaire
Cela permet d'avoir Nx propriétaires pour une propriété et
Nx popriétés pour un même propriétaire.
Autrement dit, une relation plusieurs à plusieurs entre la table
T_Propriétés et T_Propriétaires
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Salut,
Albert wrote:Bonjour / Bonsoir
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Table UN Liste des individus avec No automatique, Champs NoAuto et
Champs NOM
Table deux avec les champs suivants
PropriétéNo, Proprio1, Proprio2, Proprio3
avec Relation un (NOM) à plusieurs les trois champs Proprio
Est-ce possible, ou puis-je trouver un exemple?
Merci de votre aide
Ne surtout pas faire cela !!!
Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?
En fait, il faut au minimum 3 tables:
T_Propriétés
-------------
# ID_Propriété
- Nom_Propriete
- ...
T_Popriétaires
----------
# ID_Proprio
- Nom_Proprio
- adresse
-
T_Popriétés_Poprios
--------------------
* ID_Propriété
* ID_Propriétaire
Cela permet d'avoir Nx propriétaires pour une propriété et
Nx popriétés pour un même propriétaire.
Autrement dit, une relation plusieurs à plusieurs entre la table
T_Propriétés et T_Propriétaires
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Je pars d'une table unique avec 79 champs,
que je veux diviser en
plusieurs tables, et j'ai presque réussi à me prendre au piège.
Donc s'inspirer de votre BDD de généalogie,
http://www.3stone.be/access/articles.php?lng=fr&pg%5
Il y aussi les proprios à contacter pour urgence, les responsables
d'entretien (pas nécessairement proprio), le proprio responsable des
finances, etc....
Pour plusieurs c'est la résidence principale, et pour plusieurs une
résidence saisonniaire.
peut-on mettre tous les noms dans la même T_Popriétaires ?
plus tard il faudra ajouter les descriptions des propriétés, et les
redevances à payer etc.....
alors je reviendrai
Je pars d'une table unique avec 79 champs,
que je veux diviser en
plusieurs tables, et j'ai presque réussi à me prendre au piège.
Donc s'inspirer de votre BDD de généalogie,
http://www.3stone.be/access/articles.php?lng=fr&pg%5
Il y aussi les proprios à contacter pour urgence, les responsables
d'entretien (pas nécessairement proprio), le proprio responsable des
finances, etc....
Pour plusieurs c'est la résidence principale, et pour plusieurs une
résidence saisonniaire.
peut-on mettre tous les noms dans la même T_Popriétaires ?
plus tard il faudra ajouter les descriptions des propriétés, et les
redevances à payer etc.....
alors je reviendrai
Je pars d'une table unique avec 79 champs,
que je veux diviser en
plusieurs tables, et j'ai presque réussi à me prendre au piège.
Donc s'inspirer de votre BDD de généalogie,
http://www.3stone.be/access/articles.php?lng=fr&pg%5
Il y aussi les proprios à contacter pour urgence, les responsables
d'entretien (pas nécessairement proprio), le proprio responsable des
finances, etc....
Pour plusieurs c'est la résidence principale, et pour plusieurs une
résidence saisonniaire.
peut-on mettre tous les noms dans la même T_Popriétaires ?
plus tard il faudra ajouter les descriptions des propriétés, et les
redevances à payer etc.....
alors je reviendrai
il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
Bonjour / Bonsoir
"3stone" a écrit dans le message de
news:i8n385$jqf$il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
J'ai fait des petites tables liées, et je vois que si je crée une
requête avec deux tables liées, je ne peux pas modfier le contenu de
mes champs.
Par ailleurs j'examine d'autres tables exemples avec deux
tables liées où on peut modifier, ajouter des champs sans problème.
Quelle est la solution, autre que le sous formulaire?
Bonjour / Bonsoir
"3stone" <sweet@home.be> a écrit dans le message de
news:i8n385$jqf$1@speranza.aioe.org...
il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
J'ai fait des petites tables liées, et je vois que si je crée une
requête avec deux tables liées, je ne peux pas modfier le contenu de
mes champs.
Par ailleurs j'examine d'autres tables exemples avec deux
tables liées où on peut modifier, ajouter des champs sans problème.
Quelle est la solution, autre que le sous formulaire?
Bonjour / Bonsoir
"3stone" a écrit dans le message de
news:i8n385$jqf$il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
J'ai fait des petites tables liées, et je vois que si je crée une
requête avec deux tables liées, je ne peux pas modfier le contenu de
mes champs.
Par ailleurs j'examine d'autres tables exemples avec deux
tables liées où on peut modifier, ajouter des champs sans problème.
Quelle est la solution, autre que le sous formulaire?
Salut,
Albert wrote:Bonjour / Bonsoir
"3stone" a écrit dans le message de
news:i8n385$jqf$il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
J'ai fait des petites tables liées, et je vois que si je crée une
requête avec deux tables liées, je ne peux pas modfier le contenu de
mes champs.
In ne faut pas mélanger les champs de deux tables, si tu ne
peux faire la mise à jour, c'est que Access ne peux définir
soit à quelle table, soit à quel enregistrement les données
appartiennent...Par ailleurs j'examine d'autres tables exemples avec deux
tables liées où on peut modifier, ajouter des champs sans problème.
Quelle est la solution, autre que le sous formulaire?
Le sous-formulaire est la meilleure manière, car la clé externe
est attribuée automatiquement dans la table secondaire.
Pour ajouter un propriétaire, il faut que la propriété existe.
Selon la nécessité, on peut également, a partir du formulaire
principal, ouvrir un formulaire qui ne sera pas "inclus" dans
ce form principal.
Une simple liste indépendante, placée en haut d'un formulaire,
et contenant la liste des propriétés, est également une bonne
alternative au formulaire principal lorsqu'il s'agit de saisir les
propriétaires.
En fait, ce qu'il faut éviter à tout prix, c'est cette organisation
horizontale comme exprimée au départ, du style :
PropriétéNo, Proprio1, Proprio2, Proprio3
Les données *doivent* être organisées verticalement.
Pour rechercher un proprio, il faut qu'ils se retrouvent tous
dans la même "colonne".
La seconde problème avec cette disposition, s'est qu'elle
rend impossible l'ajout de nouveaux proprio... alors que
lorsqu'il sont "en colonne", il n'y a pas de limite.
Une table très large, avec beaucoup de champ, est presque
toujours le signe d'une mauvaise organisation. A l'inverse, il
ne faut pas créer des tables inutiles...
La question qu'il faut à chaque fois se poser est: à qui
appartient cette donnée ?...
Salut,
Albert wrote:
Bonjour / Bonsoir
"3stone" <sweet@home.be> a écrit dans le message de
news:i8n385$jqf$1@speranza.aioe.org...
il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
J'ai fait des petites tables liées, et je vois que si je crée une
requête avec deux tables liées, je ne peux pas modfier le contenu de
mes champs.
In ne faut pas mélanger les champs de deux tables, si tu ne
peux faire la mise à jour, c'est que Access ne peux définir
soit à quelle table, soit à quel enregistrement les données
appartiennent...
Par ailleurs j'examine d'autres tables exemples avec deux
tables liées où on peut modifier, ajouter des champs sans problème.
Quelle est la solution, autre que le sous formulaire?
Le sous-formulaire est la meilleure manière, car la clé externe
est attribuée automatiquement dans la table secondaire.
Pour ajouter un propriétaire, il faut que la propriété existe.
Selon la nécessité, on peut également, a partir du formulaire
principal, ouvrir un formulaire qui ne sera pas "inclus" dans
ce form principal.
Une simple liste indépendante, placée en haut d'un formulaire,
et contenant la liste des propriétés, est également une bonne
alternative au formulaire principal lorsqu'il s'agit de saisir les
propriétaires.
En fait, ce qu'il faut éviter à tout prix, c'est cette organisation
horizontale comme exprimée au départ, du style :
PropriétéNo, Proprio1, Proprio2, Proprio3
Les données *doivent* être organisées verticalement.
Pour rechercher un proprio, il faut qu'ils se retrouvent tous
dans la même "colonne".
La seconde problème avec cette disposition, s'est qu'elle
rend impossible l'ajout de nouveaux proprio... alors que
lorsqu'il sont "en colonne", il n'y a pas de limite.
Une table très large, avec beaucoup de champ, est presque
toujours le signe d'une mauvaise organisation. A l'inverse, il
ne faut pas créer des tables inutiles...
La question qu'il faut à chaque fois se poser est: à qui
appartient cette donnée ?...
Salut,
Albert wrote:Bonjour / Bonsoir
"3stone" a écrit dans le message de
news:i8n385$jqf$il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...
J'ai fait des petites tables liées, et je vois que si je crée une
requête avec deux tables liées, je ne peux pas modfier le contenu de
mes champs.
In ne faut pas mélanger les champs de deux tables, si tu ne
peux faire la mise à jour, c'est que Access ne peux définir
soit à quelle table, soit à quel enregistrement les données
appartiennent...Par ailleurs j'examine d'autres tables exemples avec deux
tables liées où on peut modifier, ajouter des champs sans problème.
Quelle est la solution, autre que le sous formulaire?
Le sous-formulaire est la meilleure manière, car la clé externe
est attribuée automatiquement dans la table secondaire.
Pour ajouter un propriétaire, il faut que la propriété existe.
Selon la nécessité, on peut également, a partir du formulaire
principal, ouvrir un formulaire qui ne sera pas "inclus" dans
ce form principal.
Une simple liste indépendante, placée en haut d'un formulaire,
et contenant la liste des propriétés, est également une bonne
alternative au formulaire principal lorsqu'il s'agit de saisir les
propriétaires.
En fait, ce qu'il faut éviter à tout prix, c'est cette organisation
horizontale comme exprimée au départ, du style :
PropriétéNo, Proprio1, Proprio2, Proprio3
Les données *doivent* être organisées verticalement.
Pour rechercher un proprio, il faut qu'ils se retrouvent tous
dans la même "colonne".
La seconde problème avec cette disposition, s'est qu'elle
rend impossible l'ajout de nouveaux proprio... alors que
lorsqu'il sont "en colonne", il n'y a pas de limite.
Une table très large, avec beaucoup de champ, est presque
toujours le signe d'une mauvaise organisation. A l'inverse, il
ne faut pas créer des tables inutiles...
La question qu'il faut à chaque fois se poser est: à qui
appartient cette donnée ?...
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Ne surtout pas faire cela !!!
Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?
En fait, il faut au minimum 3 tables:
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Ne surtout pas faire cela !!!
Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?
En fait, il faut au minimum 3 tables:
J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.
Ne surtout pas faire cela !!!
Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?
En fait, il faut au minimum 3 tables: