[Base] Requête SQL de comptage

fr-users
#21

...Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf
erreur c'estun problème lié à la version de HSQLDB, antédiluvienne
(1.8), alors que laversions actuelle est 2.51. ...on achoppe sur
des trucs aussi basiques que cette syntaxe SQL
défaillante,incomplète. C’est rageant.

j'ai effectivement été freinée dans mon usage de Base, à chaque fois
que j'ai voulu utiliser un peu de SQL...

Voilà qui m'étonne. Ce serait lié à quoi ?

Dans les fichiers d'exemples que je suis en train de traduire, je trouve des usages de SQL (et qui fonctionnent) que je ne soupçonnais pas. Mais je ne suis pas un spécialiste, juste un amateur un peu éclairé...

J'ai découvert trés récemment cette limitation qui est pourtant
parfaitement documentée. C'est trés simple de prendre du txt ou du csv,
du dbf pour en faire une base, mais les fonctionnalités sont de fait
plus limitées.

A mon avis, cette fonctionnalité est implémentée pour faciliter l'usage des sources de données et quelques traitements simples. Mais certainement pas à recommander.

Je rappelle que la question initiale était : "grouper les absences d'un élève sur une seule page" à partir d'un fichier CSV. J'ai donc répondu à cette question, en faisant simple, sans créer de base intégrée.
J'étais loin de me douter qu'on partirait dans des comptages SQL !

Est-ce qu'il existe (je n'ai pas cherché..) suffisament de doc pour
guider dans la conversion de base en format texte ou classeur vers
HSQLDB ? Est-ce que la doc Base 6.4 qui est en cours de traduction,
notamment par Jean Michel je crois, intègre cette info ?

Il n'y a pas plus. J'ai réalisé il y a quelque temps un outil pour exporter une feuille Calc en requête SQL, mais ça n'a intéressé personne. Il fallait de toute manière créer la base intégrée avant l'import SQL.

@Thierry, pas d'accès concurrent avec Base à ma connaissance, ce qui
est aussi limitant. Ex : un formulaire de saisie (qui alimente la base
x) utilisable par 2 personnes en même temps...

Il y a une bidouille possible en créant des comptes dans HSQLDB, mais je n'ai jamais testé, et je doute un peu de l'intégrité des données... Ça fait partie des tests que j'aimerais bien faire. Cela dit, un serveur Mysql (ou MariaDB) sur un poste du réseau utilisé avec Base sur plusieurs postes, ça fonctionne bien aussi.

Bonne soirée à tous...

#22

Pour ce qui est de la date sous la forme "Le ...", c'est un peu simplifié mais c'est effectivement sous forme de texte.qu'est fournie la plage de dates.
Ceci vient d'un export CSV du logiciel de Vie scolaire "Pronote".
Je pourrais demander qu'ils incluent des champs supplémentaires un peu plus normalisés... pour une mise en place dans 18 mois.

Si les dates ne sont pas au format Date dans la base, pas de tri possible...

Ma finalité, c'est que l'utilisateur.ice (un.e collègue) fasse le job en un minimum d'étapes :
- lancer l'export CSV Pronote et enregistrer le fichier CSV dans un dossier dédié,
- ouvrir un fichier Writer préparé pour le publipsotage lié au CSV,
- lancer les exports de publipostages individuels en PDF.

Avec le projet complet, on voit mieux où il faut aller !

Pronote ne fait pas des rapports sur les absences ?

Bonne soirée,

#23

Bonsoir,

Re,

Pour en avoir le coeur net je viens de créer une table neuve, avec initialement deux colonnes : nom, date. Au cours de la création, HSQLDB exige une colonne d'index (normal en somme). Je l'ai donc laissé faire, en modifiant juste la propriété de la colonne ID créée en la mettant en incrément automatique.

J'ai alimenté cette table avec les requêtes suivantes, une légère extension du fichier .csv initial :

INSERT INTO "absences" ("nom", "date") VALUES ('Larry', 'Le 05/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 07/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 12/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 18/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 01/10/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 25/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 27/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 05/10/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Henri', 'Le 21/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Henri', 'Le 25/09/20');

A ce stade la table contient :

SELECT * FROM "absences"

2,Larry,Le 05/09/20,
3,Larry,Le 05/09/20,
4,Sarah,Le 07/09/20,
5,Sarah,Le 12/09/20,
6,Sarah,Le 18/09/20,
7,Sarah,Le 01/10/20,
8,Anna,Le 25/09/20,
9,Anna,Le 27/09/20,
10,Anna,Le 05/10/20,
11,Henri,Le 21/09/20,
12,Henri,Le 25/09/20,

Il y a deux "Larry" ensuite d'autres manipulations...

Manifestement, l'index doit lui plaire car j'obtiens ceci :

SELECT "nom", COUNT(*) FROM "absences" GROUP BY "nom";

Larry,2,Larry,
Sarah,4,Sarah,
Anna,3,Anna,
Henri,2,Henri,

Mais par contre, le format de sortie est incorrect, je ne vois pas pourquoi le nom est répété ni pourquoi il y a systématiquement une virgule en fin de ligne.

Là, je suis d'accord. Mais ceci survient en utilisant Outils/SQL et en affichant la sortie des instructions "Select" ?
Parce qu'en enregistrant la requête, le résultat au format table est conforme.

Si je modifie la requête ainsi :
SELECT "nom", COUNT(*) AS "cnt" FROM "absences" GROUP BY "nom";

J'obtiens ceci :

Larry,2,Larry,
Sarah,4,Sarah,
Anna,3,Anna,
Henri,2,Henri,

La renommage de la colonne COUNT(*) ne se fait pas, ce qui indique qu'il y a vraiment des trucs bizarres qui flottent dans le potage.

Bien sûr que si, si on regarde la requête au format table, après avoir créé la requête. Pas en exécutant pas Outils/SQL, bien entendu.

Au passage, tiens, le GROUP BY tout pourri s'est mis à fonctionner ?

Bref, il semble qu'en créant une clé unique on parvienne à faire fonctionner partiellement les fonctions d'agrégation, mais franchement, je ne compterais pas trop dessus, d'autant plus si la sortie est choucroutée.

Si, si, ça fonctionne parfaitement, en utilisant les requêtes, qui sont faites pour être enregistrées et utilisées plus tard dans des formulaires ou des rapports.

Peut-être qu'un jour, une nouvelle version, ou un autre moteur, qui sait... Moi, je m'arrête là pour ce sujet.

Il vaut mieux, car ça donne une (fausse) image négative ce ce logiciel.

Ah, par contre si on veut connaître la date de la dernière absence de chaque élève, voici comment faire (ATTENTION, les DATES sont bien sûr traitées comme du TEXTE. D'où ma remarque précédente !) :

SELECT DISTINCT a."nom", a."date" FROM "absences" a  WHERE a."date" = SELECT MAX(b."date") FROM "absences" b WHERE a."nom" = b."nom";

Anna,Le 27/09/20,
Henri,Le 25/09/20,
Larry,Le 05/09/20,
Sarah,Le 18/09/20,

Et comme les dates sont au format texte, le résultat est faux. Avec des dates au bon format, le résultat est correct.

Bonne soirée,

--

Jean-Michel Coste

#24

Bonsoir,

Après une petite réflexion sur le sujet, pour faire le plus simple pour l'utilisateur (à mon sens, bien entendu), je créerais d'abord une table  avec Nom, Prenom, Absence_1, Absence2, .... Absence_15 (il m'a semblé qu'il y avait un maximum de 15?).

Puis, par macro ou requête, en parcourant la table originale, remplir cette nouvelle table (après l'avoir vidée de la session précédente, bien entendu). On a donc une ligne par élève, avec toutes ses absences. Après ça, le publipostage est très facile, puisqu'il suffira d'intégrer le nom et les 15 champs (dont une grande majorité sera vide) dans la page adéquate du document final.

Le plus difficile sera peut-être de lancer la procédure sans utiliser Base (la base devra être la, de toute façon).

Il y a peut-être une solution directe avec Calc, ou tout simplement une macro, qui, traitant le fichier CSV, fabrique un autre CSV au format de la fameuse table définie ci-dessus, le publipostage à partir de ce fichier est aisé également.

Je retourne contempler les vagues avec mon vélo pour quelque temps.... mais le problème m'intéresse.

Bien cordialement,

#25

Bonjour,

Je rappelle que la question initiale était : "grouper les absences d'un élève sur une seule page" à partir d'un fichier CSV. J'ai donc répondu à cette question, en faisant simple, sans créer de base intégrée.
J'étais loin de me douter qu'on partirait dans des comptages SQL !

Alors... La question était :
Dans un publipostage (fonctionnalité pour laquelle j'utilise encore Word), fusionner sur une page tous les enregistrements qui ont une valeur de champ en commun.

"Publipostage" étant une fonctionnalité à mon avis clairement définie sous LO.

Désolé de ne l'avoir écrit que 2 fois, et pas assez explicitement.

#26

Bonsoir,

SELECT "nom", COUNT( * ) AS "Nb" FROM "absencesCsV2" GROUP BY "nom";

Normal, avec des tables texte, l'agrégation n'est pas possible. Mais la doc en français est (encore) inexistante, je suis en train de la traduire)

Ben voilà la cause de base de toutes ces questions. Voilà. Voilà.

Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf erreur c'est un problème lié à la version de HSQLDB, antédiluvienne.

Eh bien oui, c'est une erreur, et ce n'est pas lié à cette version, qui, bien qu'antédiluvienne, fonctionne parfaitement, et permet des requête bien plus complètes.

Bien plus complètes, SAUF avec des tables texte.

#27

Bonsoir,

Ma finalité, c'est que l'utilisateur.ice (un.e collègue) fasse le job en un minimum d'étapes :
- lancer l'export CSV Pronote et enregistrer le fichier CSV dans un dossier dédié,
- ouvrir un fichier Writer préparé pour le publipsotage lié au CSV,
- lancer les exports de publipostages individuels en PDF.

Après une petite réflexion sur le sujet, pour faire le plus simple

Puis, par macro ou requête, en parcourant la table originale, remplir cette nouvelle table (après l'avoir vidée de la session précédente, bien entendu). On a donc une ligne par élève, avec toutes ses absences. Après ça, le publipostage est très facile, puisqu'il suffira d'intégrer le nom et les 15 champs (dont une grande majorité sera vide) dans la page adéquate du document final.

Il y a peut-être une solution directe avec Calc, ou tout simplement une macro, qui, traitant le fichier CSV, fabrique un autre CSV au format de la fameuse table définie ci-dessus, le publipostage à partir de ce fichier est aisé également.

C'est tout le dilemme du projet :

- OU je trouve une solution intégrée avec une suite bureautique qui est :
   1. simplissime à mettre en place pour l'utilisateur Lambda ET
   2. facilement transmissible car sans macro ou fonctionnalité au-delà de la bureautique

- OU je pars dans du traitement personnalisé de données avec scripts nécessaires et là je passe tout de suite en Javascript sur des Google Sheets avec GSuite Education.

#28

Bonjour,

Merci de l'aide. La colonne 'Qte' reste toujours vide.

Même avec un simple
SELECT
    "nom", "date_absence",
    ( SELECT COUNT( * ) FROM "absencesCsv2" ) "Qte"
FROM "absencesCsv2"

la colonne 'Qte' reste vide...

Voilà, comme vous avez pu le lire et l'apprendre peut-être comme moi, les requêtes de Base sur les tables texte de type CSV sont très limitées, notamment Group by qui n'est pas fonctionnel.

En fait une solution intermédiaire serait de créer une base HSQLDB, puis une table avec la structure du fichier CSV, puis les requêtes ;
pour mettre à jour le contenu de la table à partir d'un nouveau fichier CSV, lancer la requête (Outils | SQL...) :

SET TABLE "absences" SOURCE "absencesCsv2.csv"

Sans clé primaire aucune, les requêtes attendues fonctionnent.

#29

Le lien de l'info :
https://forum.openoffice.org/en/forum/viewtopic.php?f=83&t=23260

#30

De la doc plus complète :
http://hsqldb.org/doc/guide/texttables-chapt.html

#31

Bonjour

Jean Michel, à te lire je crois que je vais apprécier la traduction que tu finis de boucler.....

>
> > > ...Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf
> > > erreur c'estun problème lié à la version de HSQLDB, antédiluvienne
> > > (1.8), alors que laversions actuelle est 2.51. ...on achoppe sur
> > > des trucs aussi basiques que cette syntaxe SQL
> > > défaillante,incomplète. C’est rageant.
> j'ai effectivement été freinée dans mon usage de Base, à chaque fois
> que j'ai voulu utiliser un peu de SQL...

Voilà qui m'étonne. Ce serait lié à quoi ?

Dans les fichiers d'exemples que je suis en train de traduire, je trouve
des usages de SQL (et qui fonctionnent) que je ne soupçonnais pas. Mais
je ne suis pas un spécialiste, juste un amateur un peu éclairé...

Je n'ai jamais cherché très loin (jusqu'au jour assez récent où j'ai trouvé la limitation des txt). Je n'ai toujours fait qu'un usage très empirique de Base. En essayant de me dépatouiller car ma syntaxe SQL qui fonctionne par ailleurs "ne semble pas fonctionner" dans Base. Mais je n'ai toujours utilisé dans Base que des csv, ods ou dbf.... Donc forcément, ça ne marchait pas. Donc lié au fait que j'ai jamais vraiment creusé plus et que j'aurais du !

> J'ai découvert trés récemment cette limitation qui est pourtant
> parfaitement documentée. C'est trés simple de prendre du txt ou du csv,
> du dbf pour en faire une base, mais les fonctionnalités sont de fait
> plus limitées.

A mon avis, cette fonctionnalité est implémentée pour faciliter l'usage
des sources de données et quelques traitements simples. Mais
certainement pas à recommander.

De mon côté je recommande cette pratique en mode passe plat :
 Je n'ai pas essayé dans les versions récentes de Calc mais manipuler des fichiers de données un peu lourd dans Calc 4.3 avait été quasi impossible jusqu'au moment où l'on a intégré les fichiers dbf comme une base. Il était a ce moment là plus confort (côté perf) de les manipuler comme source de données dans Calc au lieu de les ouvrir directement avec Calc, mais ça mériterait d'être retesté....

Je rappelle que la question initiale était : "grouper les absences d'un
élève sur une seule page" à partir d'un fichier CSV. J'ai donc répondu à
cette question, en faisant simple, sans créer de base intégrée.
J'étais loin de me douter qu'on partirait dans des comptages SQL !

> Est-ce qu'il existe (je n'ai pas cherché..) suffisament de doc pour
> guider dans la conversion de base en format texte ou classeur vers
> HSQLDB ? Est-ce que la doc Base 6.4 qui est en cours de traduction,
> notamment par Jean Michel je crois, intègre cette info ?
Il n'y a pas plus. J'ai réalisé il y a quelque temps un outil pour
exporter une feuille Calc en requête SQL, mais ça n'a intéressé
personne. Il fallait de toute manière créer la base intégrée avant
l'import SQL.

Je n'ai pas vu passer ou en tout cas ça me dit rien.

> @Thierry, pas d'accès concurrent avec Base à ma connaissance, ce qui
> est aussi limitant. Ex : un formulaire de saisie (qui alimente la base
> x) utilisable par 2 personnes en même temps...

Il y a une bidouille possible en créant des comptes dans HSQLDB, mais je
n'ai jamais testé, et je doute un peu de l'intégrité des données... Ça
fait partie des tests que j'aimerais bien faire.

Ce serait intéressant a tester oui !

Cela dit, un serveur
Mysql (ou MariaDB) sur un poste du réseau utilisé avec Base sur
plusieurs postes, ça fonctionne bien aussi.

Disons que si j'ai un serveur de données, j'aurais plutôt un sgbd et que l'usage de Base tombe...
jusqu'à maintenant en tout cas et en mode pro car l'idée c'est justement de faire sans.

Bonne soirée à tous...

--
Jean-Michel

Merci Jean Michel. Bonne journée

Claire

#32

Bonjour,

Bonjour,

Je rappelle que la question initiale était : "grouper les absences d'un élève sur une seule page" à partir d'un fichier CSV. J'ai donc répondu à cette question, en faisant simple, sans créer de base intégrée.
J'étais loin de me douter qu'on partirait dans des comptages SQL !

Alors... La question était :
Dans un publipostage (fonctionnalité pour laquelle j'utilise encore Word), fusionner sur une page tous les enregistrements qui ont une valeur de champ en commun.

Et ça fonctionne avec un publipostage sous Word ?

"Publipostage" étant une fonctionnalité à mon avis clairement définie sous LO.
Désolé de ne l'avoir écrit que 2 fois, et pas assez explicitement.

J'avais bien compris. Mais jamais question de SQL (ce qui est le fond de ma remarque....)

#33

Bonsoir,

Ma finalité, c'est que l'utilisateur.ice (un.e collègue) fasse le job en un minimum d'étapes :
- lancer l'export CSV Pronote et enregistrer le fichier CSV dans un dossier dédié,
- ouvrir un fichier Writer préparé pour le publipsotage lié au CSV,
- lancer les exports de publipostages individuels en PDF.

Après une petite réflexion sur le sujet, pour faire le plus simple
Puis, par macro ou requête, en parcourant la table originale, remplir cette nouvelle table (après l'avoir vidée de la session précédente, bien entendu). On a donc une ligne par élève, avec toutes ses absences. Après ça, le publipostage est très facile, puisqu'il suffira d'intégrer le nom et les 15 champs (dont une grande majorité sera vide) dans la page adéquate du document final.

Il y a peut-être une solution directe avec Calc, ou tout simplement une macro, qui, traitant le fichier CSV, fabrique un autre CSV au format de la fameuse table définie ci-dessus, le publipostage à partir de ce fichier est aisé également.

C'est tout le dilemme du projet :

- OU je trouve une solution intégrée avec une suite bureautique qui est :
  1. simplissime à mettre en place pour l'utilisateur Lambda ET
  2. facilement transmissible car sans macro ou fonctionnalité au-delà de la bureautique

S'il s'agit juste de cliquer sur un bouton pour lancer la macro, j'ai un bon nombre d'utilisateurs qui s'en satisfont, sans rien y connaître. Toute la question est de savoir quelle autonomie on accorde à l'utilisateur, et à quel suivi le concepteur sera contraint.

- OU je pars dans du traitement personnalisé de données avec scripts nécessaires et là je passe tout de suite en Javascript sur des Google Sheets avec GSuite Education.

Ouhla ! Ce serait un gros saut....

Cordialement,

#34

Bonjour,

Bonjour

Jean Michel, à te lire je crois que je vais apprécier la traduction que tu finis de boucler.....

Je n'ai jamais cherché très loin (jusqu'au jour assez récent où j'ai trouvé la limitation des txt). Je n'ai toujours fait qu'un usage très empirique de Base. En essayant de me dépatouiller car ma syntaxe SQL qui fonctionne par ailleurs "ne semble pas fonctionner" dans Base. Mais je n'ai toujours utilisé dans Base que des csv, ods ou dbf.... Donc forcément, ça ne marchait pas. Donc lié au fait que j'ai jamais vraiment creusé plus et que j'aurais du !

Il y a une seconde manière d'utiliser les fichiers texte dans une base HSQLDB interne, que je n'avais pas pris le temps de proposer, honte sur moi (et que Stéphane vient de découvrir). Dans ce cas les fonctions sont opérationnelles.

Cela dit, un serveur
Mysql (ou MariaDB) sur un poste du réseau utilisé avec Base sur
plusieurs postes, ça fonctionne bien aussi.

Disons que si j'ai un serveur de données, j'aurais plutôt un sgbd et que l'usage de Base tombe...
jusqu'à maintenant en tout cas et en mode pro car l'idée c'est justement de faire sans.

Pour des "petites structures", des formulaires Base pour nourrir ou interroger une base Mysql, lancer des publipostages avec Writer, et créer des rapports, ça permet aux  utilisateurs de n'avoir qu'un seul outil "Bureautique". Et ils apprécient.

Cordialement,

#35

Bonsoir,

C'est tout le dilemme du projet :

- OU je trouve une solution intégrée avec une suite bureautique qui est :
  1. simplissime à mettre en place pour l'utilisateur Lambda ET
  2. facilement transmissible car sans macro ou fonctionnalité au-delà de la bureautique

S'il s'agit juste de cliquer sur un bouton pour lancer la macro, j'ai un bon nombre d'utilisateurs qui s'en satisfont, sans rien y connaître. Toute la question est de savoir quelle autonomie on accorde à l'utilisateur, et à quel suivi le concepteur sera contraint.

D'accord, mais *ET* le point 2.
Mon souci est d'avoir une solution qui demande le minimum de compétences spécialisées (programmation particulièrement) afin que d'autres personnes puissent mettre le nez dedans en prenant la suite.

- OU je pars dans du traitement personnalisé de données avec scripts nécessaires et là je passe tout de suite en Javascript sur des Google Sheets avec GSuite Education.

Ouhla ! Ce serait un gros saut....

Ah mais ça je le fais régulièrement, si c'était un travail que pour moi, ...
Mon autre souci est que Google Suite prend de plus en plus de place dans le lycée, je cherche alors à proposer des alternatives qui ont une valeur ajoutée par rapport aux solutions GSuite.

#36

Bonsoir

j'avais loupé celui-là

Bon si tu veux t'amuser à faire une macro tu peux, mais quand même ta
question me parait plus simple que tout ça

Dans Calc

une feuille "données", tu y prévois un copier coller de ton export de
ProNote, tu joues avec l'arrière plan, la mise en evidence de la
cellule à partir de laquelle ton collègue fait "coller"....
une feuille "source publipostage", à partir de laquelle tu prévois
l'ensemble des formules utiles
pour le regroupement, utilise un max.si (avec condition sur l'élève)
Si c'est proNote qui te sort les dates au format le jjmm/aaaa, tu
prévois une fonction droite, qui extrait la date seule, puis s'assure
qu'elle sera bien interprétée comme un nombre (cnum)

Pour ne pas perturber tes collègues, tu masques tes formules avec un si
ND => ""

Tu fais de ce fichier un modèle, tes collègues auront à
1- faire l'export pro note
2- créer un nouveau fichier ods à partir du modèle
3- enregistrer ce fichier, l'utiliser comme source du publipostage
(feuille "source publipostage"). Et si tu gères correctement nom et
emplacement de l'ods, cela ne demande pas plus de manip aux collègues
que de juste lancer la fusion.

Là dedans c'est la mise en forme pour faire un truc tout zoli qui prend
du temps... ça marche trés bien, une démo auprès des collègues c'est
bluffant (bon dans mon cas c'est pas un export pro notes, c'est autre
chose, mais ça revient au même...)

Donc tu peux toujours faire une macro, mais ça peut enfermer ceux de
tes collègues qui voudraient faire un peu évoluer le calcul et ne sont
pas à l'aise en macro...
Tu peux faire avec Base, car il y a un potentiel insoupçonné, comme le
prouve les échanges de ces derniers jours. Pour creuser Base, c'est un
super cas pratique. Mais la solution peut aussi passer par Calc :wink:

Bonne soirée

Claire

#37

Bonjour,

> > Cela dit, un serveur
> > Mysql (ou MariaDB) sur un poste du réseau utilisé avec Base sur
> > plusieurs postes, ça fonctionne bien aussi.
> Disons que si j'ai un serveur de données, j'aurais plutôt un sgbd et que l'usage de Base tombe...
> jusqu'à maintenant en tout cas et en mode pro car l'idée c'est justement de faire sans.

Pour des "petites structures", des formulaires Base pour nourrir ou
interroger une base Mysql, lancer des publipostages avec Writer, et
créer des rapports, ça permet aux utilisateurs de n'avoir qu'un seul
outil "Bureautique". Et ils apprécient.

Trés franchement, je n'en doutes pas un instant. Disons que pour un
usage perso, ce n'est pas un problème.
Dans le contexte pro, mettre à dispo une base MySql ce n'est pas
envisageable, on serait plutôt sur du postgre, et de façon distante, il
y aurait donc toujours un sgbd à coté, ou un outil de type R ou SAS
pour créer le fichier utile en publipostage.
Quand les bases de données sont légères, ou jetables, mes chers
collègues ont le réflexe tableur, Ils vont jusqu'à créer des liens
multiples entre fichiers tableurs, comme de réelles BDD
relationnelles... J'aimerais les amener sur la logique base de données,
c'est plus cohérent. Donc vraiment je ne rejette pas Base, mais il y a
quelque chose à creuser ! Et pour moi l'enjeu se déplace un peu car il
s'agira alors de savoir quand est-ce qu'on passe directement via le
sgbd, les traitements R etc, et quand est-ce qu'on peut se satisfaire
de Base.

Cordialement,

--
Jean-Michel Coste

Bonne soirée

Claire

#38

Bonsoir,

Bon si tu veux t'amuser à faire une macro tu peux,

Je disais justement que je cherche à tout prix à faire SANS Macro avec LibreOffice sauf si devient indispensable, auquel cas je change d'outil.

mais quand même ta question me parait plus simple que tout ça

Dans Calc

une feuille "données", tu y prévois un copier coller de ton export de
ProNote, tu joues avec l'arrière plan, la mise en evidence de la
cellule à partir de laquelle ton collègue fait "coller"....
[...]
3- enregistrer ce fichier, l'utiliser comme source du publipostage
(feuille "source publipostage").

C'est ce sur quoi je m'oriente maintenant... :slight_smile:

#39

Bonjour,

Je rappelle que la question initiale était : "grouper les absences d'un élève sur une seule page" à partir d'un fichier CSV. J'ai donc répondu à cette question, en faisant simple, sans créer de base intégrée.
J'étais loin de me douter qu'on partirait dans des comptages SQL !

Alors... La question était :
Dans un publipostage (fonctionnalité pour laquelle j'utilise encore Word), fusionner sur une page tous les enregistrements qui ont une valeur de champ en commun.

Et ça fonctionne avec un publipostage sous Word ?

Oui.
https://heureuxoli.developpez.com/office/word/publipostage/#LVI-C

"Publipostage" étant une fonctionnalité à mon avis clairement définie sous LO.
Désolé de ne l'avoir écrit que 2 fois, et pas assez explicitement.

J'avais bien compris. Mais jamais question de SQL (ce qui est le fond de ma remarque....)

La question initiale était
"Y a-t-il possibilité (intégrée, facile) ..."

sans demander de SQL.

Le recours ultérieur à SQL est pour pallier au manque de fonctionnalité intégrée de "publipostage 1-n" dans LibreOffice.

#40

Bonsoir,

Et ça fonctionne avec un publipostage sous Word ?

Oui.
https://heureuxoli.developpez.com/office/word/publipostage/#LVI-C

Belle hérésie ! la base clients et la base achats dans deux feuilles Excel, ça ferait hurler tout bon responsable informatique.

Et puis "sans programmation" avec du code SQL, ça me semble bizarre. Et l'exemple ne semble pas fonctionnel de manière simple.

Le recours ultérieur à SQL est pour pallier au manque de fonctionnalité intégrée de "publipostage 1-n" dans LibreOffice.

Si Word répond au problème et pas LibreOffice, il vaut mieux rester avec Word.

Bonne soirée