Discussion :

[Miflon]

Bonjour à tout le monde.
Je fais de la programmation en amateur et j'aimerais construire une application utilisant une base de données sur les animaux pour ma fille en BTS GPN.
Le problème des accents n'est pas nouveau au vu des posts que l'on trouve tant en anglais qu'en français. Je n'ai pas été capable de faire fonctionner les solutions proposées et je sollicite votre aide. Voici les versions des logiciels que j'utilise :
Windows XP3.
Lazarus #:0.9.30 i386-win32/win64.
FPC 2.4.2
Wampserver 2.1 (MySQL 5.5.8 et PHPMyAdmin 3.3.9)
Le problème ne semble pas venir de MySQL car la consultation au moyen de la console fait un usage correct des accents. La base de données que j'ai entrée utilise la page de code utf8 et utf8_general_ci pour la collation.
Dans un premier temps j'ai utilisé les composants SQLdb livrés avec Lazarus pour constituer une application conforme à celle proposée à :
http://wiki.lazarus.freepascal.org/MySQLDatabases (Cf. fichier joint pour la feuille)
Une erreur surgissait au moment de la sélection d'une table dont le nom comportait une lettre accentuée. Différents messages mettaient en avant les composant ZEOS, que j'ai installés. Amélioration, je peux maintenant sélectionner une table dont le nom comporte une lettre accentuée et la liste des champs est écrite correctement avec les accents. J'ai également ajouté les propriétés conseillées au composant ZConnection :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
character_set_client=utf8_general_ci
character_set_connection=utf8_general_ci
character_set_database=utf8_general_ci
character_set_results=utf8_general_ci
character_set_server=utf8_general_ci
character_set_system=utf8_general_ci
collation_connection=utf8_general_ci
collation_database=utf8_general_ci
collation_server=utf8_general_ci
Codepage=utf8

Mais quand je veux lancer une requête du genre 'select * from félinés' elle est refusée car comportant un caractère erroné :
SQL Error : Invalid character string : 'f\xC3'
La sélection des bases ou des tables se fait par TComboBox, la requête est entrée par TEdit, ces trois composants ont des polices en UNICODE.
Si je copie/colle le nom de la table à partir du TComboBox la même erreur est retournée.
Si j'utilise la fonction utf8Encode pour le texte de la requête, elle est acceptée en tant que telle mais le message suivant est envoyé :
SQL Error: 'Table animaux.fã@linã@s' doesn't exist' (signe @ à la place du signe copyright)
En ce moment je regarde du côté de la configuration de MySQL, mais je n'en sort pas grand chose.
Merci pour votre aide.

[Miflon]

Re bonjour.
Je viens d'essayer la requête suivante :
'show columns from félinés'
et là cela fonctionne les accents sont acceptés dans la requête le TEDit étant en DEFAULT_CHARSET. Bon j'aimerais recupérer les données et non les titres de colonnes dans le DBGrid!
Je n'y comprend rien.

[chris37]

Bonjour,

Un petit tour ici et par ici pourra vous aidez

Cordialement,
Chris

[tintinux]

Bonjour

Est-ce que tu as essayé avec des noms de table et de champs sans accents ?

Cela n'est pas complètement bien supporté par Zeos et SqlDb, et c'est aussi déconseillé si ton application doit être un jour utilisée par des anglophones.

Pour les données en français, tu sembles avoir fait ce qu'il faut et il ne devrait pas y avoir de problème en UTF-8.

[Miflon]

Bonjour à tous.
Pour Chris37:
Je connais le second ici (http://lazarus-fr.espace-malin.fr/in...nees&Itemid=14). J'ai essayé les conseils prodigués mais cela n'a pas marché. Je vais mettre en oeuvre les propositions du premier ici (http://lazarus-fr.espace-malin.fr/in...ntent&Itemid=4). Merci pour ton implication.

Pour Tintinux:
Je ne suis pas, par principe, favorable à l'abandon des accents en français alors qu'il existe des paramétrages qui fonctionnent (utf8) pour tout un ensemble d'autres langues. J'ai pourtant effectué cet essai pour valider les principes mis en oeuvre par le programme. Essai dont les résultats ont été conformes à ce que j'en attendais. Les accents apparaîssaient dans les colonnes du DBGrid. Mais ce qui m'ennuie c'est que les tables ont des noms sans accents et que félinés devient felines. Cela m'ennuerait aussi de faire un tableau de correspondance entre les noms des tables avec et sans accents. De plus l'application sera à usage intra familial, avec tout au plus une utilisation à la soutenance du rapport de stage de ma fille. Je ne suis qu'un retraité qui aime bien finir ses phrases par de points virgules, pas plus. Merci pour ton empathie.
Je promets d'être moins bavard pour les prochains posts.

[tintinux]

Bonjour

Je suis tout à fait d'accord avec ta position de principe, mais on n'y peut pas grand chose, à part aider les développeurs de Zeos à améliorer encore leur outil...

Toutefois, pour ton projet, et à mon humble avis, cela ne me semble pas être une pratique "normale" de créer une table par famille. Je crois qu'il serait préférable de faire une table des familles et une ou plusieurs tables "détail" référençant les familles. Si les "propriétés" des familles sont très différentes, et pour éviter trop de champs inutilisés, il faut peut-être une table très générique (idfamille, idpropriété, valeur). Avec des jointures tu obtiendras tout ce dont tu as besoin.

[Miflon]

Bonjour à tous.
Pour Tintinux.
Je n'en suis malheureusement pas encore à l'organisation de la base de données. Mon objectif actuel est de me familiariser avec les BDD et leur gestion avec Lazarus. Et je piétine!!
Le règne animal est organisé en embranchements, classes, ordres, familles genres et espèces. Je pensais faire une table, avec index, par élément et faire des jointures pour voir la position de l'espèce dans cette structure. Cela ressemble très fort à l'organisation d'un disque dur.
Il existe d'autres BDD.
Sont-elles plus performantes pour la gestion de nos cinq malheureuses voyelles accentuées et du o e entrelacé?
Peut-on les classer par ordre de "puissance" (nombre d'enregistrement, rapidité...).
Existe-t-il des sites de comparaison de ces BDD?
Merci pour tout.

[Gouyon]

Je déconseille fortement de mettre les noms de table avec des accents. C'est comme les noms de variable dans les langages de programmation ça ne passe pas (ou très mal manifestement pour mysql)

D'autre part sur la copie d'écran j'ai vue une fenêtre dans laquelle tu mets une requête SQL. C'est peut être pratique mais c'est très dangereux. Il vaut mieux utiliser des composants TZQuery (pour Zeos) et mettre la requête en dur dans le programme.

Exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
  Query := TZQuery.Create(nil);
  Query.Connection := CADM.LaBase;
  Query.SQL.Clear;
  Query.SQL.Add('SELECT Email FROM t_participants WHERE  Status = "ORG"');
  Query.Open;
  if not (Query.EOF) then
  begin
    MailOrganisateur := Query.FieldValues['Email'];
    ......
  end;
  Query.Free;

En plus ça résoud le problème d'accent puisqu'on peut imaginer par exemple un bouton avec le texte suivant "Rechercher Félinés" avec une requête derrière qui ira chercher les infos dans la table felines
Je suggère aussi d'utiliser un data module. C'est une fiche un peut particulière qui va contenir tous les éléments de la base de donnée.

Quant à l'organisation des données il faut peut être regarder du coté des forum SQL s'il n'y a pas déjà des stuctures de données similaires et quelles solutions ont été apportées

[tintinux]

Bonsoir

Très heureux de t'aider, mes anciennes études en biologie serviront peut-être enfin un peu...

Le plus naturel et le plus simple serait à mon avis sans doute de faire une table pour chaque niveau : embranchements, classes, ordres, familles, genres et especes. Chacune d'elles aura au moins 3 colonnes : identifiant, id. pere et nom. Il y aura je crois, surtout dans la table des espèces, d'autres colonnes descriptives en texte libre ou en images, et probablement des colonnes à valeurs numériques ou logique de certaines
caractéristiques ou propriétés (p.ex : population, continents).

Des esprits brillants t'inciteront peut être à te lancer dans un arbre intervallaire, bien documenté sur ce site, mais à mon avis c'est difficile et surtout inadapté à l'arbre phylogénétique qui a des niveaux bien définis.

Pour ce qui est du choix du SGBD, ne te fais pas trop de souci, ce n'est pas très important pour ton projet. MySql est très bien, mais tu peux aussi envisager SqlLite, un peu plus simple à installer, et suffisant si tu ne prévois pas plusieurs utilisateurs simultanés. Dans tous les cas choisis l'Utf8 et tu pourras mettre des accents dans les données, mais pas dans les noms de tables.

Bon courage !

[Invité]

Bonjour,

Même en faisant abstraction des éventuels problèmes d'accents, je ne pense pas qu'UTF8 soit toujours à conseiller en mySQL, en tous cas en version 5. Je n'utilise pas de 6.

Par exemple, si on construit 2 tables ainsi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE TABLE `TESTANSI` (
`IDT1` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`CHP1` VARCHAR( 255 ) NOT NULL ,
`CHP2` VARCHAR( 255 ) NOT NULL 
) ENGINE = MYISAM CHARACTER SET latin1 COLLATE latin1_general_ci;
 
ALTER TABLE `TESTANSI` ADD UNIQUE `KeyTEST1` ( `CHP1` , `CHP2` ) 
 
CREATE TABLE `TESTUTF8` (
`IDT2` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`CHP1` VARCHAR( 255 ) NOT NULL ,
`CHP2` VARCHAR( 255 ) NOT NULL 
) ENGINE = MYISAM CHARACTER SET utf8 COLLATE utf8_general_ci;
 
ALTER TABLE `TESTUTF8` ADD UNIQUE `KeyTEST2` ( `CHP1` , `CHP2` ) 
MySQL a répondu:  
#1071 - Specified key was too long; max key length is 1000 bytes

En latin1, pas de problème mais ce n'est pas le cas en UTF8. Je viens de vérifier cette différence de comportement avec l'exemple ci-dessus sur une mySQL Version 5.0.90 lorsqu'on veut créer un index unique sur plusieurs champs "longs". On peut rencontrer ce problème par exemple dans un fichier clients où l'on veut imposer l'unicité des nom-prénom-(adresse-)ville ou quelque chose du même genre. La raison de l'erreur signalée : http://www.developpez.net/forums/d64...-was-too-long/
Peut-être que cela passe maintenant en Version 6.

Par contre en SQLite3, un CREATE UNIQUE INDEX KeyTEST ON TESTSQLITE(CHP1, CHP2); ne pose pas de problème particulier.
Cordialement. Gilles

[Miflon]

Bonjour à tous.
Pour Gouyon:
L'application dont la copie d'écran figure dans mon message est une transposition peu ou pas modifiée d'un exemple trouvé à cette adresse : http://wiki.lazarus.freepascal.org/MySQLDatabases. Le composant TEdit permettant d'écrire la requête m'aurait permis, s'il n'y avait eu ce problème des accents, de lancer des requêtes depuis l'application et donc de m'exercer à manipuler les données d'une BDD de l'intérieur d'une application Lazarus. Dans le programme que j'envisage, les requêtes seront prises en charge par le code et non écrites par l'utilisateur.
Le mode console de MySQL gère très bien les accents dans les noms de base, de table et de champs. Dans l'application en question, les noms de BDD avec des accents déclenchent une erreur. Les noms de tables avec accents permettent de récupérer les titres des colonnes mais lorsqu'ils sont incorporés dans un TZQuery pour récupérer les données dans un DBGrid stoppent le programme. Par contre les accents présents dans les différents champs sont bien retranscrits dans le DBGrid.

Pour Tintinux:
L'application prévue sera mono-utilisateur. Si le besoin s'en fait sentir elle pourra être multi-utilisateur par la suite. L'import-export des données ne doit pas présenter trop de difficultés à ce que j'en ai lu en parcourant les forums et FAQ.
Questions :
En quoi les arbres intervallaires ne sont pas adaptés aux niveaux bien définis de l'arbre phylogénétique?

Pour Selzig:
J'ai testé tes requêtes sur MySQL version 5.5.8 et le message suivant m'a été retourné :
#1071 - Specified key was too long; max key length is 1000 bytes
Donc cela n'a pas évolué depuis ta version de MySQL.

Merci à tous pour vos informations et commentaires.

[tintinux]

En quoi les arbres intervallaires ne sont pas adaptés aux niveaux bien définis de l'arbre phylogénétique?

Un arbre intervallaire permet de stocker des données avec un nombre quelconque de niveaux, et de lire très vite tous les parents, ou tous les enfants, ou tous les frères, d'un nœud donné. Ce n'est pas ce dont tu as besoin ici.

La mise à jour est lente et la création d'un seul nœud requiert plusieurs instructions SQL, à mettre dans une transaction. La logique est assez complexe et difficile à maîtriser au début.

Je crois que c'est "un marteau-pilon pour écraser une mouche".

[Gouyon]

J'ai fait quelques tests et effectivement ça ce passe mal quand on met des accents dans les noms de table. Mais encore une fois j'insiste sur le fait que ce n'est pas très bon de mettre les nom de table avec des accents surtout que je n'en vois pas vraiment l'utilité.

[chris37]

Hum !

Il est fortement déconseillé de mettre des caractères exotiques et autres singularités dans le nom des champs, des tables, des index, etc.....

Pas d'espace non plus et des titres cours également

Cordialement,
Chris