Aller au contenu
  • 0
Sébastien Bauer

Un modèle pour plusieurs tables ?

Question

Bonjour et bonne année !

pour ma part, je commence l'année en me plongeant dans mon FMP 14 laissé un peu en jachère depuis son achat,
et ce que j'y trouve me plait bien (il faut dire que je fais un "bond" depuis la version 6 !)

Une question me vient d'emblée :

ma solution est constituée de plusieurs fichiers (version 6) qui pourraient simplement devenir plusieurs tables distinctes dans un même fichier.
L'intérêt que j'y vois serait de pouvoir définir un modèle unique (par exemple la liste de membres, identique pour tous) mais affichant les enregistrements de la table dont je veux imprimer la liste. MAIS .... comment faire ?

Merci de vos réponses éclairées.

 

Sébastien

PS : en fait, existe-t-il un moyen de changer la table source d'un modèle (par script, par exemple) ?

Partager ce message


Lien à poster
Partager sur d’autres sites

10 réponses à cette question

Messages recommandés

  • 0

Bonjour,
Je ne comprend pas très bien la question.
Dans l'exemple que vous prenez, il n'y aurait dans le nouveau fichier qu'une table Membres (avec éventuellement un(des) champ(s) pour distinguer différents types de membres), un seul modèle Impression_Membres et un(des) script(s) pour lister et imprimer tout ou partie des enregistrements de cette table Membres.

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Bonjour,

 

pour mon cas perso : j'ai un fichier "groupes" avec une table par groupe comprenant identification des membres + des infos propres au groupe en question. Cependant, les modèles basiques sont identiques (listing simple, étiquettes enveloppes, etc...)

d'où la question de savoir comment n'avoir qu'un modèle d'enveloppe (par exemple) utilisable pour tous les groupes

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0
Il y a 1 heure, Puimoisson04 a dit :

il n'y aurait dans le nouveau fichier qu'une table Membres (avec éventuellement un(des) champ(s) pour distinguer différents types de membres), un seul modèle Impression_Membres et un(des) script(s) pour lister et imprimer tout ou partie des enregistrements de cette table Membres.

Si je comprends bien, la solution c'est d'avoir tout au même endroit et de filtrer ?

ce qui revient à utiliser une multivaluée pour l'appartenance aux groupes. J'ai lu que les rubriques multivaluées étaient à éviter, non ?

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Oui, en principe si on peut les éviter, évitons-les.

Dans ton cas, qu'est ce qui fait l'appartenance à un groupe ? Peut-on appartenir à plusieurs groupes ?

Ces questions vont déterminer (au moins en partie) ce que tu pourrais faire.

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Je commence à comprendre le problème, je vais essayer de le transcrire pour être sûr de ne pas dire de bêtises. 

Un ensemble de fichiers sous FM6, chaque fichier correspond à un groupe. Chaque fichier a la même structure et utilise un modèle identique pour l'affichage et l'impression. Tu réunis le tout dans un seul fichier FM14 avec autant de tables que d'anciens fichiers. Pour l'impression tu souhaites n'avoir qu'un seul modèle.

A mon avis, le plus simple est de n'avoir qu'une seule table dans laquelle tu importeras toutes les fichiers anciens. Cette table aura par contre un nouveau champ (rubrique) GROUPE. Une simple recherche sur le groupe te permettra de n'afficher que les enregistrements concernés.

Une table GROUPE te permettra de mieux gérer les différents groupes. Pour rebondir sur ce que dis Bruno, reste le cas d'appartenir à plusieurs groupes. Dans ce cas précis, l'utilisation de multivaluée est justifié. A toujours utiliser avec parcimonie.

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Merci de vos éclairages qui confirme mes craintes. Le point négatif de la multivaluee, c’est quand une personne appartenant à plusieurs groupes en quitte un et pas les autres. En ayant une table par groupe, on supprime l’enregistrement. Avec une seule table, il faut tester si la personne appartient à plusieurs groupes, effacer une entrée s’il reste d’autres groupes ou supprimer si c’était le dernier. C’est plus complexe...

 

d’où l’idée de séparer déjà données et modèles pour éclaircir un peu

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Tu es confronté la complexité d'une base de données lorsque certaines de ses données peuvent avoir plusieurs valeurs. Une solution est les tables intermédiaires. Derrière ce nom ambigu se cache la solution à ton problème. Il te faut une table des groupes, une table des personnes et une table avec uniquement la personne et le groupe (ou mieux uniquement l'ID de la personne et l'ID du groupe). Avec des liens et des occurrences de table bien définis, tu affectes une personne à un groupe, tu la retires d'un groupe et tu peux rechercher toutes les personnes d'un groupe. C'est un peu plus savant, un peu plus long à mettre en place mais ça répond à ta question !

Partager ce message


Lien à poster
Partager sur d’autres sites
  • 0

Philippe,

je vois le schéma global, et avec la puissance des scripts associés aux fenêtres multiples, je pense m’en sortir. Heureusement qu’il reste encore quelques longues soirées d’hiver ;-)

en tous cas, grand merci pour votre aide. Merci également à Bruno S. d’avoir pris la peine de lire et de s’intéresser à mon cas. 

Je reviendrai vous dire si j’ai abouti à quelque chose de probant.

Sébastien

Partager ce message


Lien à poster
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant


  • En ligne récemment   0 membre est en ligne

    Aucun utilisateur enregistré regarde cette page.

×