Ça correspond à ce que j'ai décrit : HSQLDB 1.8 ne connaît pas le GROUP BY.
Par contre cela n'a rien à voir avec l'origine des données. Pour vous en
convaincre, créez une nouvelle table avec deux colonnes VARCHAR, alimentez-les
par des requêtes INSERT puis exécutez vos tests sur elles, vous obtiendrez le
même résultat.
Le csv n'est qu'une répétition de lignes ayant la même structure, dont les
éléments sont séparés par des virgules (historiquement). Rien de magique
là-dedans.
Au cas où:
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', ´25/09/2020´); devrait
fonctionner si votre table se nomme absences et les deux colonnes nom et date.
> Le 21 oct. 2020 à 22:57, Stéphane Santon <m.libreoff...@santonum.eu> a écrit :
>
> Bon...
>
> J'aurais fait ça :
>
> SELECT "a"."nom", "a"."date_absence", "b"."lastdate"
> FROM "absencesCsv3" "a"
> INNER JOIN (
> SELECT "nom", MAX( "date_absence" ) "lastdate"
> FROM "absencesCsv3"
> GROUP BY "nom" ) "b"
> ON "a"."nom" = "b"."nom"
> ORDER BY "nom", "date_absence"
>
> Mais le champ lastdate du MAX reste vide comme pour le COUNT...
>
> Si je ne fais rien que :
> SELECT nom, MAX(date_absence) lastdate from absencesCsv3 GROUP BY nom
>
> il me répond :
> "La requête ne peut pas être exécutée. Elle est trop complexe. Seul «
> COUNT(*) » est pris en charge."
>
> Probablement parce que ma table est du texte issu de CSV et non une vraie
> table HSQLDB...
>
> --
> Envoyez un mail à users+unsubscr...@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
--
Envoyez un mail à users+unsubscr...@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
