Re: [fr-users] Re: [fr-users] [Base] Requête SQL encore, MAX d'un champ

Ç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.libreoffice@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+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

-- 
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