Date: prev next · Thread: first prev next last
2024 Archives by date, by thread · List index


Bonsoir

il faudrait éviter les suppositions rapides, d'autant que nous n'aviosn aps les fichiers auparavant. Je n'ai pas eu le temps de les regarder, mais replaçons les choses. Puisqu'il aurait mieux vallu garder le même fil...

L'outil actuellement créé utilise Calc & Base. Ainsi si l'on rajoute des calculs dans Calc, ceux ci sont pris en compte dans Base, ce qui n'est pas souhaité... (c'est un raccourci aussi, mais après tout les archives de la liste sont là pour retracer les choses). Il y a déjà eu des interventions pour recommander l'utilisation de Base seul. La réponse donnée etait : non, pas de formulaire de saisie dans Base, ce n'est pas adapté aux utilisateurs cibles. J'ai proposé en 1er lieu pour une évolution minimale, l'utilisation de 2 fichiers Calc, dont un fichier "tampon", qui serait utilisé par Base. Je ne sais pas pourquoi cette solution ne convient pas. Peut être n'est-elle pas adaptée à la problématique, c'est à voir avec les fichiers envoyés.

Ensuite, si je reconnais la puissance de Base, on a droit d'être quelques peu réalistes. Si Base est installé en même temps que Calc (sous Windows du moins), cela ne signifie pas que pour un utilisateur standard, la connaissance même trés basique de Base est aussi fréquente que celle de Calc. Bien sur, l'investissement peut être réduit, mais si l'on a l'habitude de travailler auprès d'utilisateurs qui doivent reprendre l'utilisation d'un outil qu'ils n'ont pas conçus : l'utilisation d'un tableur impressionne moins... En résumé, cela fait déjà plusieurs jours que l'on sait que l'ensemble est parfaitement réalisable en intégralité, uniquement dans Base. Ce n'est malgré tout pas la solution retenue par la personne qui pose la question. Qui sait aussi que dans d'autres outils pro, l'ensemble serait aussi parfaitement réalisable. Le prisme d'entrée est donc la maintenabilité, dont les critères sont définis par la personne qui pose la question, et non par les principes d'usage de chaque outil. Donc soit on continue le spaghetti en essayant de combiner Calc et Base ce qui semble délicat, soit on cherche une autre solution. à savoir, est-ce possible dans Calc, même si, rigoureusement, dans Base, ce serait plus adapté. Et oui, ça permettrait une architecture plus simple (que Calc & Base et non que Base seul) Une fois ceci dit, si François est prêt à faire du Base tout court, y compris pour la saisie, banco. Si Jean Michel peut gérer l'effet de bord soumis la semaine dernière entre Calc et Base, banco aussi.

De mon coté, les prochains jours sont chargés comme je l'avais déjà dit, il va falloir patienter un peu avant que je puisse regarder ces fichiers (à moins qu'une autre option soit choisie d'ici là !)

En tous cas, merci pour les fichiers ! à suivre

Claire

Le 2024-09-01 08:05, Jean-Michel PIERRE a écrit :
Puisqu’il s’agit de gérer une association et que les calculs sont très simples à paramétrer dans les requêtes (codes SQL Count ou Sum) ou les rapports de Base, les conseils de n’utiliser que Calc peuvent être dus à une méconnaissance de Base.


Jean-Michel PIERRE
Tél : 06.19.55.73.22

Le 31 août 2024 à 21:46, François SAINT-CHRISTOPHE <francois.saint-christophe@orange.fr> a écrit :




Bonsoir,

c'est bien la situation actuelle : j'utilise base et en partie calc. Dans des échanges précédents avec la liste, il m'a été indiqué que il était possible d'abandonner la partie Base pour tout avoir sous calc. Au des exemples fournis, pensez vous que cela soit possible ? En tout cas, je n'ai pas réussi.

Cordialement

envoyé : 31 août 2024 à 17:46
de : Jean Michel PIERRE <jmpniort@orange.fr>
à : "francois.saint-christophe@orange.fr" <francois.saint-christophe@orange.fr> objet : Re: [fr-users] Développement avec base de données : Calc ou Base ?


Bonjour,

Les États attendus, ainsi que les spécifications souhaitées, semblent tout à fait réalisables directement dans le module Base.

Les requêtes dynamiques s'ajustent sans difficulté au nombre adhérents, en choisissant les critères voulus. Il est possible de concaténer prénom et nom et de faire un tri, sur l'un ou l'autre.

On peut aussi ajouter la création d'une carte d'adhérent avec sa photo, des listings sur les critères souhaités, par exemple les dates d’adhésion ou de cotisation payée, etc.

Enfin, s'il est nécessaire de sortir des données dans Calc, c'est possible directement avec le Rapport de Base, ou comme actuellement en faisant glisser une requête pour la déposer dans le classeur.



Bonsoir
Ces derniers jours, j'ai échangé avec la liste principalement sous 2 fils de discussion. Au cours de ces échanges, j'ai reçu des remarques ou propositions d'architecture différente pour un outil que j'ai développé. Pour éviter de repartir avec des objets de post qui n'ont plus beaucoup à voir avec le sujet que je veux aborder, je repars donc avec un nouveau fil d'échanges, en rappelant le contexte, puis en posant la question qui me préoccupe. Pour les besoins d'une section d'un club auquel j'appartiens, j'ai développé un outil qui permet de faire la gestion nécessaire :
- saisie du fichier adhérent dans un .ods

- à partir de ce fichier adhérents, production des différents sous produits ou états : état financier des cotisations, liste des adhérents de la section à destination du club, comparaison automatique des données avec celles de la fédération nationale,

- développé sous libre office. Le .ods est également défini en .odb. Des requêtes attachées à l'odb permettent d'extraire les données et sont intégrées dans des feuilles de l'ods (1 feuille = 1 sous produit

- aucune ligne de programmation ni de macro, ceci pour des raisons de facilité de maintenance et de prévision de passage de relais vers une personne maîtrisant les aspects bureautiques mais ne programmant pas. Tout est basé sur des requêtes, des formules de calcul et des manip simples pour l'utilisateur.

Actuellement, la saisie se fait directement dans le .ods, sans formulaire, avec une validation de données effectuée par la fonction standard de calcul.

Lors d'échanges avec la liste, il m'a été proposé de ne plus utiliser Base et de tout effectuer dans Calc. L'idée parait intéressante et je pourrai migrer l'outil vers cette nouvelle architecture, sous réserve :

  *
de ne pas dégrader le fonctionnement pour l'utilisateur,
  *
de simplifier l'architecture
  *
de conserver une maintenabilité facile possible pour le repreneur de la maintenance.

Pour faciliter les échanges et la compréhension de l'architecture et de ma question, j'ai préparé une maquette reflétant précisément la technique utilisée mais appliqué sur des fichiers exemples avec peu de données. Ci-après un lien qui renvoie vers un fichier ods et vers un fichier odb (l'odb n'a pas besoin d'être référencé dans LO). Dans le fichier ods, plusieurs feuilles. La 1ère comporte un texte expliquant chaque feuille. La succession de ces feuilles a été faite dans l'ordre où j'ai raisonné et testé pour ai final, mettre en oeuvre la solution calc+base :

  *
une feuille données saisies,
  *
puis l'image d'un état tel que je le souhaite avec 10 lignes, et 14 lignes de données,
  *
puis les résultats obtenus avec 2 méthodes sous calc seul
  *
et enfin, la dernière feuille contient la solution calc+base.

Peut être suis je arrivé à cette solution en étant passé à côté des fonctionnalités BD de Calc tout seul. Je sollicite donc les membres de la liste pour leurs propositions éventuelles de solutions alternatives plus simples.

Merci par avance

Lien vers fichiers maquette
https://partage.isidorus.fr/f.php?h=1U_nDfCk&d=1



--
Jean-Michel PIERRE
19 rue François VILLON
79000 NIORT
tél : 0619557322

--
Claire

--
Envoyez un mail à users+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.