Aller au contenu

Sébastien Bauer

Membres
  • Compteur de contenus

    11
  • Inscription

  • Dernière visite

À propos de Sébastien Bauer

  • Rang

Profil général

  • Genre
    Homme
  • Lieu
    ALSACE

Profil FileMaker

  • FM Conférence
    Un jour j'irai !
  • FM
    FMP14
  • OS
    OSX.10
  • Certification
    --Non certifié--
  • FBA
    --Non membre--
  1. Sébastien Bauer

    Un modèle pour plusieurs tables ?

    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
  2. Sébastien Bauer

    Un modèle pour plusieurs tables ?

    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
  3. Sébastien Bauer

    Un modèle pour plusieurs tables ?

    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 ?
  4. Sébastien Bauer

    Un modèle pour plusieurs tables ?

    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
  5. Sébastien Bauer

    Un modèle pour plusieurs tables ?

    Note à moi-même et ceux que ça peut intéresser : voir quelle utilité des solutions proposées ici ( )
  6. Sébastien Bauer

    Un modèle pour plusieurs tables ?

    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) ?
  7. Sébastien Bauer

    Sébastien Bauer

  8. Sébastien Bauer

    Même script pour plusieurs tables ?

    A l'ancienne, oui ! haha ! quant au monde entre la v6 et la v14, je l'expérimente chaque jour et c'est la raison de ma présence ici ;-) Ma base est une base de personnes (légalement déclarée à la CNIL) dont l'historique de "construction" justifie trois modifications de structure depuis 1998. En effet, au départ (version 1) ne nous intéressait que la gestion des personnes, puis il est apparu que la connaissance des liens familiaux (parent-enfants) serait utile, d'où la version 2. Ce fut encore assez facile... Mais depuis quelques années, la notion de famille recomposée est venue compliquer un peu plus tout ça, aboutissant à la version 3. La 4ème version que je développe actuellement (il n'y a pas d'urgence puisque la 3 remplie encore son rôle) devrait aplanir ces différentes conceptions (je te passe le nombre d'heures de réflexion déjà passées) et mes questions sont plus pratiques que structurelles. Le recours au archives séparées sont juste le garant d'une possibilité de contrôle supplémentaire par ce que j'appelle "la théorie des couches"... Dans l'intervalle entre nos échanges, j'ai déjà un peu avancé en trouvant la fonction "définir rubrique par nom" qui me simplifiera vachement la tâche ! merci de ton intérêt, je ne manquerai pas de faire appel à tes connaissances s'il y a encore des soucis pratiques ;-) (et je conçois qu'il existe des aberrations dans ma façon de faire... je fais un travail sur moi pour essayer de changer, mais c'est plus fort que moi... haha !)
  9. Sébastien Bauer

    Même script pour plusieurs tables ?

    Certes, sauf à garantir l'unicité des enregistrements dans les tables, et pouvoir tester les doublons facilement... je n'aime pas imbriquer les recherches sur des critères "essentiels" de la base Il est vrai que je tâtonne encore un peu sur la méthodologie que je veux utiliser, d'où mon inscription en ces lieux : je cherche aussi à débattre de mes choix pour les valider / Merci de m'accorder quelques minutes pour ça :-)
  10. Sébastien Bauer

    Même script pour plusieurs tables ?

    question subsidiaire : du coup, comment faire référence aux noms de rubriques (identiques dans toutes les tables) ? est-ce que $nomdetable::nomderubrique est valable ?
  11. Sébastien Bauer

    Même script pour plusieurs tables ?

    Merci pour ce premier avis, je me doutais "qu'avec des si, on pourrait..." :-))) Concrètement, comme je migre mes bases v6 vers la nouvelle base v14, je vais me retrouver très vite à faire le même traitement et les mêmes requêtes sur 12 ou plus tables importées, que je voudrais garder afin de pouvoir les traiter plus tard comme des archives interrogeables. En donnant comme nom de table l'année de l'archive, j'imagine qu'il me serait possible de faire mon traitement sur la table voulue avec une boite de dialogue qui demanderait juste la valeur du paramètre "année"... et irait chercher dans la table correspondante. A partir d'un bouton unique, avec un script unique au lieu de 12+ ;-)
  12. Sébastien Bauer

    Même script pour plusieurs tables ?

    Bonjour, Pour mon premier message, quelques mots de présentation : Utilisateur de FMP6 depuis la fin des années 1990, je viens de passer à la version 14 (!). Autant dire que j'ai loupé quelques mises à jour. D'où ma question pour m'assurer de ne pas manquer une procédure simple apparue dans les versions 7 à 14... Alors voilà : Je m'aperçois qu'il me serait possible d'utiliser un même script pour le traitement de plusieurs tables, si je pouvais y ajouter un paramètre "nomdetable". Comment procéder le plus simplement ? Merci de votre aide ! Sébastien
×