Re: [fr-users] Re: [LibreOffice BASE] REQUÊTE problème de colonne calculée

Bonjour Pierre-Yves,

Le 30/05/2021 à 08:15, pierre-yves samyn a écrit :
> Bonjour
>
> Un site d'assistance n'est actif que si on pose des questions :)
> En l'occurence je t'aurais donné les éléments suivants.
Certes...mais je suis trop souvent cassé les dents sur des forums 
inactifs, et je préfère perdre quelques secondes à sélectionner la façon 
de demande de l'aide, que perdre quelques jours à attendre une réponse 
qui ne vient jamais sur un forum inactif. Chat échaudé craint l'eau 
froide ;-)
Mais si vous y étiez, effectivement, ça aurait fonctionné ! Je note
(j'ai finalement l'impression que vous êtes nombreux à préférer le forum ?)
> larb wrote
> > Les tables texte comme base d’une base de données autonome
> > ...
> > Si on ne peut pas utiliser de fonctions, ça explique donc pourquoi ma
> > colonne reste toujours vide !
> Les possibilités sont très réduites mais on peut utiliser
> quelques fonctions. Tu peux par exemple obtenir un résultat très
> approchant comme ceci :
>
> SELECT "promotion", LOCATE( 'µ', CONCAT( 'µ', "promotion" ) ) "yapromo" FROM
> "test"
>
> Ceci crée une colonne "yapromo" contenant 1 pour les enregistrements
> ayant un champ "promotion" non vide.
Effectivement, je viens de tester, ça fonctionne. Comment peut-on 
connaître les fonctions qui "fonctionnent" ? alors que la doc officielle 
dit que les fonctions ne sont pas autorisées ?
Cependant, ça pose quand même un problème dans mon cas : la colonne est 
soit "vide" soit égale à 1...impossible de faire une somme sur ce type 
de données dans un tableau croisé dynamique dans CALC.
Mais merci pour l'astuce : intéressant !
> larb wrote
> > Tables de texte dans une base de données HSQLDB interne
> > ...
> > je n'ai pas de clé primaire numérique dans mon fichier CSV...donc
> > impossible de lier la table
> On peut tout à fait faire des jointures dans une requête sur
> un champ autre qu'une clé primaire : il suffit que les types
> de champ le permette.
>
> Pour revenir à la question, dans ce type de base on peut utiliser
> par exemple :
>
> SELECT casewhen( "promotion" IS NULL, 0, 1 ) "yapromo" FROM
> "NomTableLiaison"
>
> Cordialement
> Pierre-Yves
En fait, mon problème avec cette table, c'est que je n'arrive même pas à 
la lier au fichier CSV. D'après la doc, j'en ai conclu que c'était à 
cause de l'absence de clé primaire.
Votre message m'a fait douter : j'ai retenté sans clé primaire. Mais 
l'exécution de la requête SQL permettant de lier la table vide (donc 
créée cette fois ci sans clé primaire) au fichier CSV abouti à une 
erreur qui n'est pas cohérente :
j'exécute SET TABLE "HistoriquePromotion" SOURCE 
"HistoriquePromo.csv;ignore_first=true;encoding=UTF-8";1
La table HistoriquePromotion possède 5 champs : Article VARCHAR(50), 
Description VARCHAR(150), Prix NUMERIC, Date Date, Promotion VARCHAR(255)

Le fichier HistoriquePromo.csv possède ces 5 champs, et jamais le type 
de données ou sa longueur ne pourrait poser problème (et certainement 
pas la 1ère ligne).
Or le message d'erreur reçu lors de l'exécution est :
bad TEXT table source file - line number: 1 Value too long in statement 
[set table "HistoriquePromotion" source 
"HistoriquePromo.csv;ignore_first=true;encoding=UTF-8"]

donc laissant penser que dès la première ligne, les données sont trop 
longues...
Or la 1ère ligne (non ignorée) est
MPX_2455127;Casa Azzurra Parmigiano reggiano râpé 60g;27/05/2021;1,15;

du coup, je n'arrive pas à aller plus loin avec cette piste....



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