Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des pièces
et
des
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage par
exemple), d'autres où il est associé à chaque appartement qui compose le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur la
table pièces.Mais il n'y aura toujours qu'un de ces trois champs qui sera
rempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des pièces
et
des
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage par
exemple), d'autres où il est associé à chaque appartement qui compose le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur la
table pièces.Mais il n'y aura toujours qu'un de ces trois champs qui sera
rempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des pièces
et
des
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage par
exemple), d'autres où il est associé à chaque appartement qui compose le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur la
table pièces.Mais il n'y aura toujours qu'un de ces trois champs qui sera
rempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Salut,
Voir message précédant.
Espérant être utile,
Vanderghast, Access MVP
"Joce" wrote in message
news:4112591b$0$31556$Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des
pièces
etdes
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage par
exemple), d'autres où il est associé à chaque appartement qui compose le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur
la
table pièces.Mais il n'y aura toujours qu'un de ces trois champs qui
sera
rempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Salut,
Voir message précédant.
Espérant être utile,
Vanderghast, Access MVP
"Joce" <nospam@freesbee.fr> wrote in message
news:4112591b$0$31556$636a15ce@news.free.fr...
Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des
pièces
et
des
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage par
exemple), d'autres où il est associé à chaque appartement qui compose le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur
la
table pièces.Mais il n'y aura toujours qu'un de ces trois champs qui
sera
rempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Salut,
Voir message précédant.
Espérant être utile,
Vanderghast, Access MVP
"Joce" wrote in message
news:4112591b$0$31556$Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des
pièces
etdes
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage par
exemple), d'autres où il est associé à chaque appartement qui compose le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur
la
table pièces.Mais il n'y aura toujours qu'un de ces trois champs qui
sera
rempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Bonsoir
Le problème est que je ne vois pas le message précédant.
Est-il possible de le placer sous ce fil ?
D'avance merci.
René
"Michel Walsh" a écrit dans le
message
de news:Salut,
Voir message précédant.
Espérant être utile,
Vanderghast, Access MVP
"Joce" wrote in message
news:4112591b$0$31556$Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des
piècesetdes
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage
par
exemple), d'autres où il est associé à chaque appartement qui compose
le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la
table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur
latable pièces.Mais il n'y aura toujours qu'un de ces trois champs qui
serarempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Bonsoir
Le problème est que je ne vois pas le message précédant.
Est-il possible de le placer sous ce fil ?
D'avance merci.
René
"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> a écrit dans le
message
de news:eQf6uqgfEHA.3520@TK2MSFTNGP10.phx.gbl...
Salut,
Voir message précédant.
Espérant être utile,
Vanderghast, Access MVP
"Joce" <nospam@freesbee.fr> wrote in message
news:4112591b$0$31556$636a15ce@news.free.fr...
Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des
pièces
et
des
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage
par
exemple), d'autres où il est associé à chaque appartement qui compose
le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la
table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur
la
table pièces.Mais il n'y aura toujours qu'un de ces trois champs qui
sera
rempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Bonsoir
Le problème est que je ne vois pas le message précédant.
Est-il possible de le placer sous ce fil ?
D'avance merci.
René
"Michel Walsh" a écrit dans le
message
de news:Salut,
Voir message précédant.
Espérant être utile,
Vanderghast, Access MVP
"Joce" wrote in message
news:4112591b$0$31556$Bonjour
J'ai une petite base pour gérer les factures de fluides pour un parc
immobilier réparti sur plusieurs sites.
J'ai une table des sites, une table des bâtiments, des étages, des
piècesetdes
appartements.
Par ailleurs, j'ai une table qui liste tous les compteurs d'eau ou
d'électricité.
Mon problème est le suivant : Le compteur est généralement associé au
bâtiment. Mais j'ai des cas où le compteur est sur le site (arrosage
par
exemple), d'autres où il est associé à chaque appartement qui compose
le
bâtiment.
Dans ma table compteur, j'ai donc créé un champ qui pointe sur la
table
site, un qui pointe sur la table bâtiment et un dernier qui pointe sur
latable pièces.Mais il n'y aura toujours qu'un de ces trois champs qui
serarempli.
Y a t'il une méthode plus rigoureuse ?
D'avance merci pour vos conseils.
René
Salut,
Une solution est de n'utiliser que deux champs, un pour le "pointeur",
un pour le "type" (quelle table). Faire des relations 1 à plusieurs, ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookup
supportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans clause
WHERE).
Pour éditer la première table avec les données de la seconde table,
faire un design form-subform, où on change le sous formulaire à la volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le source
object refère au formulaire de compteur pour batiment, et quand on a un
site, le sous formulaire change et affiche à nouveau un sous formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
Salut,
Une solution est de n'utiliser que deux champs, un pour le "pointeur",
un pour le "type" (quelle table). Faire des relations 1 à plusieurs, ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookup
supportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans clause
WHERE).
Pour éditer la première table avec les données de la seconde table,
faire un design form-subform, où on change le sous formulaire à la volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le source
object refère au formulaire de compteur pour batiment, et quand on a un
site, le sous formulaire change et affiche à nouveau un sous formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
Salut,
Une solution est de n'utiliser que deux champs, un pour le "pointeur",
un pour le "type" (quelle table). Faire des relations 1 à plusieurs, ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookup
supportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans clause
WHERE).
Pour éditer la première table avec les données de la seconde table,
faire un design form-subform, où on change le sous formulaire à la volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le source
object refère au formulaire de compteur pour batiment, et quand on a un
site, le sous formulaire change et affiche à nouveau un sous formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
Bonsoir
Et merci pour le temps consacré à ma question.
Mais la réponse appelle une autre question de béotien.
Qu'est-ce qu'un champ 'lookup' qui supporte une requête ?
D'avance merci, René
"Michel Walsh" a écrit dans le
message
de news:%Salut,
Une solution est de n'utiliser que deux champs, un pour le
"pointeur",
un pour le "type" (quelle table). Faire des relations 1 à plusieurs, ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookupsupportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans
clause
WHERE).
Pour éditer la première table avec les données de la seconde table,
faire un design form-subform, où on change le sous formulaire à la volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le source
object refère au formulaire de compteur pour batiment, et quand on a un
site, le sous formulaire change et affiche à nouveau un sous formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
Bonsoir
Et merci pour le temps consacré à ma question.
Mais la réponse appelle une autre question de béotien.
Qu'est-ce qu'un champ 'lookup' qui supporte une requête ?
D'avance merci, René
"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> a écrit dans le
message
de news:%23dj3JXsfEHA.1644@tk2msftngp13.phx.gbl...
Salut,
Une solution est de n'utiliser que deux champs, un pour le
"pointeur",
un pour le "type" (quelle table). Faire des relations 1 à plusieurs, ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookup
supportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans
clause
WHERE).
Pour éditer la première table avec les données de la seconde table,
faire un design form-subform, où on change le sous formulaire à la volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le source
object refère au formulaire de compteur pour batiment, et quand on a un
site, le sous formulaire change et affiche à nouveau un sous formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
Bonsoir
Et merci pour le temps consacré à ma question.
Mais la réponse appelle une autre question de béotien.
Qu'est-ce qu'un champ 'lookup' qui supporte une requête ?
D'avance merci, René
"Michel Walsh" a écrit dans le
message
de news:%Salut,
Une solution est de n'utiliser que deux champs, un pour le
"pointeur",
un pour le "type" (quelle table). Faire des relations 1 à plusieurs, ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookupsupportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans
clause
WHERE).
Pour éditer la première table avec les données de la seconde table,
faire un design form-subform, où on change le sous formulaire à la volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le source
object refère au formulaire de compteur pour batiment, et quand on a un
site, le sous formulaire change et affiche à nouveau un sous formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
Salut,
Lorsque on est en mode de design d'une table, pour le type de donnée,
il
y a un "type de donnée" qui s'appelle "lookup wizard..." (j'ignore le
terme
français). Si on utilise cette option, l'onglet Lookup (tout en bas, à
gauche) a une propriété Display Control maintenant affectée à "Combo
Box".
On peut redéfinir la requête SQL (Row Source) de sorte à y ajouter une
clause WHERE, et, par la suite, assigner LimitToList à Yes. Les valeurs,
pour le champ, seront non seulement limités à la relation simple
d'intégrité
(faire partie de la table référée) mais à une relation "complexe", car les
valeurs seront limitées à un PARTIE SEULEMENT des valeurs de la table
reférée (limitée par la clause WHERE de la requête).
Noter, par contre, que cette relation n'est pas maintenue par l'engin
de
la base de données, mais seulement par l'édition de la table (ou par
défaut
pour les nouveaux formulaires qui en dérivent). Par exemple, il sera
possible de créer un formulaire qui ne forcerait pas les données "à celles
de la liste", qui ne forcerait donc pas le "limit to list". En d'autres
mots, cela "aide" grandement dans un cas comme celui qui est décrit où on
désirerait une table "virtuelle" comme table référée, mais c'est pas
réellement totalement à toute épreuves, du moins, pas comme l'est une
relation d'intégrité standard (définie via la fenêtre d'édition de
requêtes).
Espérant être utile,
Vanderghast, Access MVP
"Joce" wrote in message
news:411a0120$0$18620$Bonsoir
Et merci pour le temps consacré à ma question.
Mais la réponse appelle une autre question de béotien.
Qu'est-ce qu'un champ 'lookup' qui supporte une requête ?
D'avance merci, René
"Michel Walsh" a écrit dans le
messagede news:%Salut,
Une solution est de n'utiliser que deux champs, un pour le
"pointeur",un pour le "type" (quelle table). Faire des relations 1 à plusieurs,
ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookupsupportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans
clauseWHERE).
Pour éditer la première table avec les données de la seconde
table,
faire un design form-subform, où on change le sous formulaire à la
volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le
source
object refère au formulaire de compteur pour batiment, et quand on a
un
site, le sous formulaire change et affiche à nouveau un sous
formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
Salut,
Lorsque on est en mode de design d'une table, pour le type de donnée,
il
y a un "type de donnée" qui s'appelle "lookup wizard..." (j'ignore le
terme
français). Si on utilise cette option, l'onglet Lookup (tout en bas, à
gauche) a une propriété Display Control maintenant affectée à "Combo
Box".
On peut redéfinir la requête SQL (Row Source) de sorte à y ajouter une
clause WHERE, et, par la suite, assigner LimitToList à Yes. Les valeurs,
pour le champ, seront non seulement limités à la relation simple
d'intégrité
(faire partie de la table référée) mais à une relation "complexe", car les
valeurs seront limitées à un PARTIE SEULEMENT des valeurs de la table
reférée (limitée par la clause WHERE de la requête).
Noter, par contre, que cette relation n'est pas maintenue par l'engin
de
la base de données, mais seulement par l'édition de la table (ou par
défaut
pour les nouveaux formulaires qui en dérivent). Par exemple, il sera
possible de créer un formulaire qui ne forcerait pas les données "à celles
de la liste", qui ne forcerait donc pas le "limit to list". En d'autres
mots, cela "aide" grandement dans un cas comme celui qui est décrit où on
désirerait une table "virtuelle" comme table référée, mais c'est pas
réellement totalement à toute épreuves, du moins, pas comme l'est une
relation d'intégrité standard (définie via la fenêtre d'édition de
requêtes).
Espérant être utile,
Vanderghast, Access MVP
"Joce" <nospam@freesbee.fr> wrote in message
news:411a0120$0$18620$626a14ce@news.free.fr...
Bonsoir
Et merci pour le temps consacré à ma question.
Mais la réponse appelle une autre question de béotien.
Qu'est-ce qu'un champ 'lookup' qui supporte une requête ?
D'avance merci, René
"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> a écrit dans le
message
de news:%23dj3JXsfEHA.1644@tk2msftngp13.phx.gbl...
Salut,
Une solution est de n'utiliser que deux champs, un pour le
"pointeur",
un pour le "type" (quelle table). Faire des relations 1 à plusieurs,
ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookup
supportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans
clause
WHERE).
Pour éditer la première table avec les données de la seconde
table,
faire un design form-subform, où on change le sous formulaire à la
volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le
source
object refère au formulaire de compteur pour batiment, et quand on a
un
site, le sous formulaire change et affiche à nouveau un sous
formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
Salut,
Lorsque on est en mode de design d'une table, pour le type de donnée,
il
y a un "type de donnée" qui s'appelle "lookup wizard..." (j'ignore le
terme
français). Si on utilise cette option, l'onglet Lookup (tout en bas, à
gauche) a une propriété Display Control maintenant affectée à "Combo
Box".
On peut redéfinir la requête SQL (Row Source) de sorte à y ajouter une
clause WHERE, et, par la suite, assigner LimitToList à Yes. Les valeurs,
pour le champ, seront non seulement limités à la relation simple
d'intégrité
(faire partie de la table référée) mais à une relation "complexe", car les
valeurs seront limitées à un PARTIE SEULEMENT des valeurs de la table
reférée (limitée par la clause WHERE de la requête).
Noter, par contre, que cette relation n'est pas maintenue par l'engin
de
la base de données, mais seulement par l'édition de la table (ou par
défaut
pour les nouveaux formulaires qui en dérivent). Par exemple, il sera
possible de créer un formulaire qui ne forcerait pas les données "à celles
de la liste", qui ne forcerait donc pas le "limit to list". En d'autres
mots, cela "aide" grandement dans un cas comme celui qui est décrit où on
désirerait une table "virtuelle" comme table référée, mais c'est pas
réellement totalement à toute épreuves, du moins, pas comme l'est une
relation d'intégrité standard (définie via la fenêtre d'édition de
requêtes).
Espérant être utile,
Vanderghast, Access MVP
"Joce" wrote in message
news:411a0120$0$18620$Bonsoir
Et merci pour le temps consacré à ma question.
Mais la réponse appelle une autre question de béotien.
Qu'est-ce qu'un champ 'lookup' qui supporte une requête ?
D'avance merci, René
"Michel Walsh" a écrit dans le
messagede news:%Salut,
Une solution est de n'utiliser que deux champs, un pour le
"pointeur",un pour le "type" (quelle table). Faire des relations 1 à plusieurs,
ou,
dans les autres tables, disons dans la table batiment, faire un champ
lookupsupportant la requête: SELECT CompteurID, CompteurDescription FROM
Compteurs WHERE type="batiment" ( au lieu du même énoncé, sans
clauseWHERE).
Pour éditer la première table avec les données de la seconde
table,
faire un design form-subform, où on change le sous formulaire à la
volée
(selong le type de compteur) via la propriété SourceObject du controle
sousformulaire. Donc, quand le compteur est pour un batiment, le
source
object refère au formulaire de compteur pour batiment, et quand on a
un
site, le sous formulaire change et affiche à nouveau un sous
formulaire
pertinent (un peu comme un Wizard).
Espérant être utile,
Vanderghast, Access MVP
