Discussion :

[Astrid69]

J'ai une table "clients" dans laquelle j'avais mis des "oui/non" sur acheteur, vendeur, prospect ... et tout le monde était mis dans la même table (sachant qu'un acheteur peut devenir aussi vendeur)
J'ai des "biens" qui sont reliés à ces "clients" (en l'occurence les vendeurs)
J'ai des "actions" effectuées sur tous types de clients

Mon soucis : j'ai des "clients" qui visitent des "biens" et j'aimerai créer un onglet "visite" en sous-formulaire. j'ai testé différentes possibilités, mais je bugge car mes biens sont attachés à des "clients", dans la même table que mes acheteurs et je me mors la queue !

J'ai réussi à créer des onglets dans "clients" avec "actions", "biens", et "recherche" (pour savoir ce que l'acheteur recherche) et je voudrai inclure un onglet "visites" pour savoir ce qu'il a visité, ce qu'il en a pensé mais aussi pouvoir recouper depuis la fiche du propriétaire et voir qui a visité ... j'ai vraiment du mal. Help !

Merci d'avance,
Astrid.

[f-leb]

Bonsoir,
Une idée serait d’employer la notion d’ héritage puisqu’un client peut avoir plusieurs rôles (acheteur, vendeur, prospect…).
En gros, tu spécialises « Client » en « Acheteur », « Vendeur », « Prospect »…
Par la suite, tu lies tes entités « bien », « action », …aux entités spécialisées (où à l’entité générique)
Ex :
Vendeur------(vendre)-------Bien
Client-----(effectuer)-----Action
Client------(visiter)-----Bien------(avoir)-----TypeBien
Acheteur------(rechercher)------TypeBien
Etc…

[Astrid69]

oui, j'ai vu ton message sur l'heritage hier, j'attends d'ailleurs avec impatience la suite du développement ;-)

Je vais tenter de bosser dessus demain, seule journée de break, mais j'ai peur de ne pas être au niveau ...

[Astrid69]

Dois-je créer des tables "vendeurs", "acheteurs", "prospects" ou s'agit il de la même table ?

[Astrid69]

voici un nouveau message que je reçois et je ne sais pas l'interpréter, et l'aide ... ne m'est d'aucune aide !
"'le paramètre de la propriété champs pères est à l'origine de l'erreur suivante : "l'objet ou la classe ne gère pas le jeu d'évênements" ...
ça me laisse dubitative !

MAY DAY !!!!

[f-leb]

Bonjour,
En fait, il y a plusieurs possibilités (dont les avantages et inconvénients sont très bien décrits dans le tuto cité plus haut):

1°) Une seule table « Client » avec un champ « Rôle »=1, 2 ou 3
Rôle=1 pour Client=vendeur, Rôle=2 pour Client=acheteur, Rôle=3 pour Client=prospect.

…J'ai des "biens" qui sont reliés à ces "clients" (en l'occurrence les vendeurs)….mais je bugge car mes biens sont attachés à des "clients", dans la même table que mes acheteurs …

Pour relier les biens aux vendeurs : Client------(vendre)------Bien, tu dois effectivement contraindre ta base (clause SQL Constraint et/ou code VBA associé à un évènement du formulaire) pour t’assurer que le client est bien un vendeur (Rôle=1).
Une autre difficulté apparaît si tu dois associer un client avec un autre client (ex : un acheteur qui paye un vendeur, « payer » est dans ce cas une association réflexive)
Client------(payer)-----Client.

2°) une table « Client » en association de type « un à un » avec de nouvelles tables « Vendeur », « Acheteur » et « Prospect ».
Conceptuellement le meilleur schéma mais qui peut compliquer les structure des requêtes et des formulaires.
La table générique « Client » comporte les caractéristiques communes à tout type de client :
Client(N°Client, NomClient, PrenomClient, AdresseClient,…..)
La table « Vendeur » (par exemple) comporte les caractéristiques spécifiques à un vendeur :
Vendeur(#N°ClientVendeur, #N°BienAVendre,…)
avec l’association de type « un à un » :Client-1---------1-Vendeur (dans la fenêtre des relations d’Access tu « tires » un trait reliant N°Client vers N°ClientVendeur)

Ex : Client(1, « leb », « f », « qquepart »,…) puis Vendeur(1, 230,…).que l’on pourra traduire par : le client N°1 (f-leb) qui habite quelque part est un vendeur dont le numéro du bien à vendre est 230 (le vendeur N°1 « hérite » des caractéristiques du client qui porte le même numéro).

Il te reste à te familiariser avec ces différentes possibilités, étudier les avantages et inconvénients…et décider du modèle qui conviendra le mieux dans ton cas.

J'ai réussi à créer des onglets dans "clients" avec "actions", "biens", et "recherche" (pour savoir ce que l'acheteur recherche) et je voudrai inclure un onglet "visites" pour savoir ce qu'il a visité, ce qu'il en a pensé mais aussi pouvoir recouper depuis la fiche du propriétaire et voir qui a visité ... j'ai vraiment du mal. Help !

Pour la suite, il s’agit (avant de penser aux formulaires) de bien structurer tes données (« Modéliser c’est construire une structure de données contraintes, représentative du réel observé »).
Les bases de la modélisation te permettront justement de sortir les tables nécessaires à partir de l’énoncé de phrases du style :
Vendeur (ou client ??)------(Vendre)------Bien-------(avoir)------TypeDeBien
Acheteur (ou client ??)-----(rechercher)-----TypeDeBien
Etc….

Bon courage …
à+

[ilank]

Bonsoir,

perso, je pense qu'on peut considèrer que vendeur et acheteur sont les deux parties d'une transaction commerciale. En clair, en dehors de toute transaction ici la vente et l'achat d'un bien, il n'y a ni acheteur ni vendeur.

Donc, je verrais plus :
une table CLIENTS pour recenser l'ensemble des clients.
une table BIENS pour recenser les biens mis en vente, dans cette table est indiqué le proprétaire actuel du bien, donc le client propriétaire qui est de fait le VENDEUR.
une table BIENS-VISITES pour recenser les dates de visites des biens mis en vente ainsi que les CLIENTS visitant le BIEN, ce sont les PROSPECTS.
une table TRANSACTION ou VENTES pour recenser les ventes des BIENS, dans cette table doit figurer en plus du BIEN , le propriétaire du BIEN appelé VENDEUR et le nouvel acquéreur appelé ACHETEUR. A l'issue de la vente, l'ACHETEUR devient le nouveau propriétaire du BIEN.

De fait, un même client peut ainsi être propriétaire donc VENDEUR d'un BIEN, PROSPECT pour un autre, ACHETEUR pour un troisième.
les VENDEURS sont l'ensemble des clients propriétaires d'un BIEN
les PROSPECTS l'ensemble des clients ayant ou devant visités un BIEN.
les ACHETEURS l'ensemble des clients ayant achetés un BIEN.