Re: [1/2 HS] syntaxe qui ne va plus depuis upgrade MySQL

[Christian Quentin]

Je ne suis pas sûr de comprendre ce que tu veux obtenir :

 * les logos distincts avec leurs images associées ? Si oui,

   SELECT DISTINCT images, logos FROM tablelogo

   devrait faire l'affaire

 * le nombre de logos distincts ? si oui, la taille du résultat de la
   requête ci-dessus te fournira l'info
 * le nombre de fois où chaque logo distinct a été rencontré lors du
   regroupement ?
   Là, il faudra utiliser

   SELECT images, logos, COUNT(logos) FROM tablelogo GROUP BY images, logos

A part ça, c'est un peu curieux d'utiliser images (au pluriel) pour 
désigner un champ qui ne contient qu'une seule image. Idem pour le champ 
logos. Mais tu n'as peut-être pas la main là-dessus.


Voilà, voilà.

Christian


Le 23/03/2017 à 13:39, andre_deb...@numericable.fr a écrit :

On Thursday 23 March 2017 11:32:10 Eric Degenetais wrote:

comment se définit le fait d'aggréger les images entre-elles? Est-ce
que les lignes ayant le même contenu pour "logo" contiennent la même
image? Dans ce cas il y a peut-être un problème de modèle. Si les
images diffèrent, comment se définit leur "aggrégation"?

Oui, n° du logo = la même image


Quel est la relation entre le nombre de ligne ayant le même contenu
pour le champ "logo", d'une part, et les images contenues, d'autre
part?

Chaque ligne (champ) "logos" contient le nom de son image :
logos   images
10toto.jpg
2   titi.jpg
10toto.jpg
2   titi.jpg
etc...

André


Le 21/03/2017 à 20:56, andre_deb...@numericable.fr a écrit :

Depuis l'installation de MySQL dernière version,
Je sèche sur une syntaxe SQL qui fonctionnait avant l'upgrade :
"SELECT images, logos, COUNT (*) AS total FROM tablelogo
GROUP BY logos ORDER BY total DESC"
Je pouvais récupérer le nombre de lignes distinctes = "logos" ($row),
ainsi que le contenu du champ = "images" ($DATA).
Maintenant, le select affiche un message d'erreur = "QUERY empty"
J'ai cherché via les sites mysql et mon script SELECT semble bon.
Si je mets ce script :
"SELECT  logos, COUNT (*) AS total FROM tablelogo
GROUP BY logos ORDER BY total DESC"
Je récupère le nombre de lignes distinctes "logos"
mais pas le contenu de "images".
Quel est le nouveau script SQL qui fonctionne pour le faire ?

Re: outil de monitoring

[Wallace]

Toutes les éditeurs communautaires ou entreprises maintiennent et
éditent leur propres repository.

Je préfère largement utiliser les dépôts de MariaDB que de faire appel
aux packages des distributions.

Debian a un modèle qui est strict et qui fait sa force, leurs packages
sont irréprochables dans la logique de localisation des fichiers, la
mise à jour. Ca plait ou pas mais c'est là et efficace.


Le 23/03/2017 à 22:36, david hannequin a écrit :
> Bonsoir,
>
> Redhat c'est une distribution serveur et c'est vendu comme ça. On aime ou pas.
>
> Debian c'est pas toujours réactif car communautaire et moi je réagis
> bien volontier sur Shinken car je suis l'auteur de l'ITP et que si tu
> ne connais personne chez Debian il n'y a aucune hésitation à  te
> piller le ton travail... Je voulais maintenir de paquet et je suis
> plutôt sérieux dans ce domaine, mets à jour les versions etc... mais
> du coup pour Fedora/EPEL.  Et il n'y aurait pas eu une demande sur la
> ML comme celle ci.
>
> De plus regarde dans le packaging officiel de Debian, il n'y a aucune
> version d'un outil de supervision "moderne".
>
> Après c'était une blague le 3eme point...
>
> Bonne soirée
>
>
>
>
>
>
> Le 22 mars 2017 à 12:01, Wallace  a écrit :
>>
>> Le 21/03/2017 à 07:57, david hannequin a écrit :
>>> Bonjour Wallace,
>>>
>>> 1/ C'est hors sujet et n'aide pas à faire le choix pour un outil de
>>> supervision ( la question de départ);
>> Je réagissait au RedHat c'est pour les serveurs.
>>> 2/ Parler de SSH sur Debian... cela me fait toujours rire depuis
>>> l'erreur introduit par les packageur du projet;
>> Les accidents ça arrive aussi à RedHat :) et d'expérience une boite
>> cache plus volontiers des incidents qu'une communauté, je préfère donc
>> être au courant par la communauté et agir en conséquence.
>>> 3/ L'artisanat c'est bien.
>> Et ça conduit à pas mal de dépense quand y a des soucis (pas de doc, pas
>> d'automatismes, coquilles et erreurs humaines en pagaille, ...)
>>> Bonne journée
>>>
>>> --
>>> Grommit
>> Oui j'utilise encore mon pseudo qui date de 1993 où à l'époque on savait
>> protéger notre identité personnelle.
>>
>
>




signature.asc
Description: OpenPGP digital signature

Re: mariadb et UTF8

[david hannequin]

Bonjour,

Normalement oui mais je te conseils de sauvegarder ta base de données
et de tester avant de le faire sur un serveur en production. Et
attention cela peut prendre du temps selon la taille des tables...

Une fois la conversion réalisé il faut aussi tester que ton
application le supporte.

Bonne journée

Le 24 mars 2017 à 04:02,   a écrit :
>
>
> - Mail original -
> De: "david hannequin" 
> À: "bernard schoenacker" 
> Cc: "debian" 
> Envoyé: Jeudi 23 Mars 2017 22:24:54
> Objet: Re: mariadb et UTF8
>
> Bonsoir,
>
> Tu as essayé ceci ?
>
> mysqldump --add-drop-table database_to_correct | replace
> CHARSET=latin1 CHARSET=utf8 | iconv -f latin1 -t utf8 | mysql
> database_to_correct
>
> Bonne soirée
>
> Le 23 mars 2017 à 20:34,   a écrit :
>> bonjour,
>>
>>
>> je recherche le moyen de corriger le tir pour mariadb et de passer du
>> latin1_swedish en utf8 ...
>>
>> le rtfm est peut bavard sur ce sujet :
>>
>> https://mariadb.com/kb/en/mariadb/setting-character-sets-and-collations/#example-changing-the-default-character-set-to-utf-8
>>
>> comment y arriver sans rien casser
>>
>> slt
>> bernard
>
>
> bonjour,
>
>
> merci pour le conseil mais je vais voir si en effaçant les tables, puis en 
> forçant
>  utf8 ça passe (?)
>
> slt
>
> bernard
>



-- 
David Hannequin