Rodolf

Membres
  • Content count

    7,022
  • Joined

  • Last visited

1 Follower

About Rodolf

  • Rank

  • Birthday 03/13/1929

Profile Information

  • Genre
    Homme
  • Lieu
    Paris -Lyon - Galeria - Lava

Previous Fields

  • FM
    13A et toutes celles d'avant
  • OS
    Mac SE et SE 30
  • Certification
    FileMaker 8 Certified Developer
  • FBA
    Membre
    Platinum
    Trainer
    Reseller

Contact Methods

  • Website URL
    http://www.demoniak.com

Recent Profile Visitors

20,779 profile views
  1. Bah, si votre secrétaire a des trous, alors tout va bien
  2. Tu crées un rubrique Choix, une fois renseignée tu déclenches ton script et avant de passer en mode recherche tu as une ligne Definir Variable ( $Var ; RubriqueChoix ) Tu as ainsi récupéré la valeur contenue dans cette rubrique
  3. Pourquoi faire un script ? Une rubrique globale (ou pas) dans laquelle tu choisis en cours ou clos, un lien entre cette rubrique et Statut et tu affiches dans une table externe tous les enregistrements liés
  4. Parce que Evaluation renvoie le contenu de la variable, sinon tu actives le modèle nommé $Layout, et ... yen a pas
  5. Initiation aux céphalées : Rue du Fg-Poissonnière Rue du Fg Poissonnière Rue du Faubourg Poissonnière Rue du Faubourg-Poissonnière Faubourg Poissonnière (qui est traduit par La Poste comme les 4 précédents)... Sachant qu'il existe aussi, à Paris, une rue Poissonnière et un Boulevard (Bv - Bvd - Bd) Poissonnière
  6. Si on crée une facture par erreur, on crée un avoir qui l'annule ou on la modifie pour que ce ne soit plus une erreur (ce qui est moins dans le dogme, mais pratique). Donc pas de n° à supprimer. PS m'étonne pas de toi, Bertrand, la table "trous"
  7. Je dirais que la limite est dans l'usage ultérieur du contenu. Mais elle est ténue... Si les fonctions ne servent qu'à apporter une précision sur la personne, une liste fera l'affaire. Mais cette liste, si on veut qu'elle puisse évoluer facilement pourra être issue d'une table des fonctions. Et c'est vrai qu'en poussant le raisonnement un peu plus loin, il est valable pour beaucoup de choses. Combien de numéros de téléphone peuvent avoir tes contacts ? Si le nombre est fixe et ne changera pas, tu peux créer les rubriques dans la table des personnes, s'il n'est pas fixe, il faut une table des N° de tél, comme pour les e-mails etc.
  8. ce qui gêne c'est "généralement"... donc il faut que tu découpes tes adresses en rubriques du genre N° - type de voie - nom. Si tu en as peu, c'est jouable et ensuite il faut forcer la saisie découpée. Sinon, les prédictions ci-dessus vont se réaliser
  9. Un fichier avec des exemples sur ce sujet assez similaire
  10. Essaye avec Evaluation ($Layout), pour avoir son contenu
  11. Pourquoi Service est-il dans la table des identités ? Un service peut comprendre plusieurs personnes (et une personne peut-elle appartenir à plusieurs services ?). Avec un tables des services, tu pourras obtenir toutes les stats que tu veux, comme tu le fais pour les personnes (et a priori sans script).
  12. Le tout étant de ne pas mélanger les choses : identifiant, valeur unique, non modifiable, c'est un code et on se fout royalement de l'ordre (après avoir longtemps utilisé aussi la formule de Maître Delapierre, j'utilise les UUID et je n'ai aucun souci). N° d'ordre implémenté et modifiable, pourquoi pas (pour trier éventuellement) et oui, pas d'autre solution que de renuméroter à chaque suppression (quoique l'ordre n'en sera pas changé pour autant, donc à quoi ça sert ?) et RIE nous parle de n° de facture, qui en effet doivent se suivrent et sans trous, mais il n'y a pas de problème puisque, normalement, on ne peut pas supprimer une facture...
  13. je pense en effet que ça sera le cas. Et d'ailleurs plus simple que l'un ou l'autre... mouette aine scie
  14. Le problème c'est d'activer un modèle (titre et début de la question) ou d'activer un enregistrement, éventuellement lié (fin de la question qui parle d'une fiche vide) ?