Version imprimable
Bonjour ;)
Mon site est en cours de mise à jour afin d'améliorer la qualité des cours et tutos sur Lazarus. Certains seront également disponibles sur DVP pour votre plus grand plaisir :P
J'ai mis à jour le complément concernant l'utilisation de Lazarus avec MySql et notament comment afficher les champs de la base de données comportant des accents :ccool:. Un petit rappel ne fait pas de mal....Vous pouvez le consulter ICI
Cordialement,
Chris
Merci pour votre travail, très aprécié.
Danilo Uccelli
Merci beaucoup pour ces tutos toujours clairs et bien faits.
Bonjour,Citation:
Problème d'affichage des accents avec Mysql
--------------------------------------------------------------------------------
Par défaut; les composants d'accès natif de Lazarus ne proposent pas la gestion UTF8 et les données ne seront pas affichées correctement dans les champs (TDBEdit, TDBGrid, etc....).
Ce problème peut également survenir avec d'autres composants d'accès comme ceux de ZEOS. Appliquer dans ce cas la même méthode que pour les composants natif.
Pour remédier à cela, placer un TSqlQuery (Name = SqlQuerySet) sur votre Form ou votre DataModule et utilisez le de la manière suivante.
Dans le code de l'évenement AFTERCONNECT du TSqlConnection, placer le code suivant
SQLQuerySet.SQL.Text : = 'SET CHARACTER SET `utf8`';
SQLQuerySet.ExecSql;
Lors de la connection, la séquence sera envoyée à la base de données et vos données seront bien affichée par la suite
à propos de mySQL et Lazarus, comme j'ai beaucoup galéré sur leur "compatibilité" et surtout pour obtenir un code polyvalent sous Windows et Linux, je me permets quelques observations qui pourront éventuellement être utiles (ou contredites) et une autre possibilité :
En Zeos, je préfère utiliser la propriété du connecteur
Il ne faut pas oublier que l'interclassement de la table peut très bien être latin1_swedish_ci alors qu'en même temps l'interclassement pour la connexion mySQL peut être en utf8_unicode_ci. Les properties peuvent le traduire. On peut le faire également avec des requêtes... mais ligne par ligne ce qui entrainent leur multiplication. Dans la majorité des cas, le code de Chris est suffisant...Code:
2
3
4
5
6
7
8
9
10
11
12
13
Concernant mySQL, quelques constatations :
1. Compte tenu de mes connaissances actuelles (et dans l'attente d'avoir "la" solution), je ne suis pas du tout partisan d'utiliser un interclassement de table UTF8 pour contenir l'alphabet français:
Le code de btUTF8 engendre une erreur : Duplication de clé unique. Pour lui lac et lâc sont identiques. Cela ramène à un vieux message sur ce forum ... alors que le "latin" fonctionne. Comme remarqué dans le message, pas de problème en UTF8 avec Postgresql avec un code adapté aux différences des 2 BDD...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
2. Le "par défaut" utilisé par Chris ne vaut malheureusement que pour un OS. Par exemple sous Linux, si la base est en UTF8, on peut se passer de "ZConnection1.Properties" et de "SET CHARACTER SET `utf8'". Ce qui "prouve" que par défaut, on est en UTF8. Le même code sous Windows génère des problèmes avec les lettres accentuées. Combien de fois ai-je obtenu des résultats différents par un même programme compilé sous Linux et sur Windows accédant sur un poste tierce où mes bases mySQL étaient hébergées. Après avoir pas mal galéré, la solution ".Properties" m'a toujours permis d'accéder à mes données (sauf parfois avec les dbMemo qui ont nécessité un travail supplémentaire). Voilà une raison qui m'amène à penser que la cross-compilation avec Lazarus et au moins hasardeuse... Le jour où Windows sera en UTF8, il faudra réexaminer la situation.
3. Enfin un petit truc, pour utiliser mySQL sous Nux sur le poste d'un utilisateur de votre programme* alors que le client mySQL n'y est pas installé où n'est pas la bonne version :
Il suffit de placer votre libmysql.so dans le répertoire du programme...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Cordialement. Gilles
*sur un poste de développement, il est toujours nécessaire d'installer mySQL client pour pouvoir utiliser toutes les fonctions de l'IDE...
Vérifié ce matin sur Lazarus 0.9.31-fpc 2.4.3 (Win&Nux) - Version du client MySQL: 5.0.32
Merci Gilles,
Je vais ajouter tes remarques au tutos sur mon site :ccool:
Jean luc sera content, il est en pleine reprise vers DVP :mouarf:
Cordialement,
Chris
Bravo très bien. Je vais enfin peut être pouvoir régler mon problème d'accents :ccool:
Sinon je suis très content de cette mise à jour. Il faudrait d'ailleurs que ce soit le cas pour pas mal d'articles. Je sais c'est beaucoup de boulot mais l'informatique évolue vite et on se retrouve assez souvent avec des articles obsolètes :cry:
Bonsoir Rémi :P
Et bien pour répondre à ta question.....
Les articles de mon site sont en cours de relecture et de correction pour coller à l'évolution de Lazarus :calim2:
D'autres articles vont venir et un travail collaboratif avec l'équipe de DVP est en train de se mettre en place mais chut, c'est un secret :ccool:
J'invite toutes celles et ceux qui ont des bouts de codes, des essais et autres proses et tutos perso à me contacter pour mettre tout cela en forme et contribuer ainsi à la promotion de ce magnifique outil de développement :oops:
Cordialement,
Chris
Message reçu. Il faut juste que je trouve le temps d'écrire quelque chose à chaque fois que je me dit "Tient ça serait bien si ça figurait dans la FAQ ou en tutoriel"Citation:
Envoyé par chris37
Bonjour,Citation:
Envoyé par selzig
Windows gère l'UTF-8 depuis très longtemps !
Ce qui compte c'est la manière dont a été crée la base par le SGBD ou le programme.
Elle est généralement créée dans un jeu de caractère ISO, mais si on peut ajouter l'option DEFAULT CHARACTER SET UTF8, il n'y a absolument rien de plus à faire sous Lazarus, quel que soit le système d'exploitation.
C'est seulement si on n'est pas maître de la création de la base, qu'il faut obligatoirement définir le jeu de caractères du client dans OnAfterConnect, comme le conseille fort justement chris37.
Mais Chris, je crois utile de mentionner le premier cas, celui où on peut créer la base, parce que c'est quand même le sens de l'histoire de passer en UTF8. Je pense que les SGBD évolueront dans ce sens, comme l'a déjà fait Lazarus.
Bonsoir TINTIN :ccool:
Je viens de modifier ce Tuto en tenant compte de ta remarque
Cordialement,
Chris
Bonjour Chris,
Je dois être aveugle, mais je ne vois pas cette modification...Citation:
D'autre part, tu écris :
Ce n'est pas exact ! Au contraire, Lazarus gère l'UTF8 nativement, et considère même que c'est le jeu de caractère par défaut. C'est justement pour cela que, quand la base est en ISO8859 (qui est le défaut de MySql), il faut faire un SET CHARACTER SET UTF8 dans le AfterConnect (c'est plus lisible sans les quotes).Citation:
Par défaut; les composants d'accès natif de Lazarus ne proposent pas la gestion UTF8 et les données ne seront pas affichées correctement dans les champs (TDBEdit, TDBGrid, etc....).
Je suggèrerais aussi d'expliquer ce que prouve l'exemple de SELZIG... qui n'a, soit dit en passant, aucun rapport avec le jeu de caractères (CHARACTER SET) mais avec les critères de tri (COLLATION), et devrait être un peu séparé, pour plus de clarté.
A mon avis, il met en évidence un bug de certaines versions de MySql, que je ne reproduis pas avec 5.1 pour Linux. Il faudrait creuser. Je pense toutefois que ça n'a pas de rapport direct avec Lazarus et qu'il serait préférable de faire ces tests avec un client indépendant. Je vais essayer, dès que possible...
Effectivement, je n'ai pas supprimmé cette ligne qui était valable pour les anciennes versions :aie: mais reste valide pour les compo d'accès aux données si on ne prend pas garde.
Lazarus gère bien l'UTF8 mais ne force pas par défaut sont utilisation avec une BDD comme d'autres progiciel.
Et puis ces tutos date un peu d'ou le besoin de mettre un peu de neuf dans tout cela. Tu as raison Tintin :)
J'ai réactivé les inscriptions et chacun peux venir ajouter ses contributions librement. Bon ce matin , OHV rencontre encore des problèmes :ccool:
Pour le complément de notre ami Selzig, j'ai juste inséré sont exemple car il serait préférable de créer un article à part. Je laisse la main à celui qui voudra bien l'écrire.
Cordialement,
Chris
Bon boulot Chris !
Bonjour,
Décidément Tintinux, c'est une manie... déjà rencontrée et qui m'avait fait réagir à l'époque (les StringGrids non buguées en 0.9.28). Je crois que les mots ont vraiment un sens intrinsèquement mais tout autant dans leur contexte. Extraire une phrase de son contexte est dans le cas présent d'un paragraphe me semble inapproprié et un tantinet inélégant.
Alors relisons-moi :
Quelle situation ? --> La cross-compilation.Citation:
Voilà une raison qui m'amène à penser que la cross-compilation avec Lazarus et au moins hasardeuse... Le jour où Windows sera en UTF8, il faudra réexaminer la situation.
Windows est capable de gérer l'UTF8. Oui. C'est un fait. Quel est le rapport avec mes propos ? Pourquoi les citer à mauvais escient ?
Et relisons la documentation de Lazarus :
Pas de problème donc... C'est limpide (Interfaces that currently use ANSI encoding, but need migration to UTF-8: win32, wince )...Citation:
Most existing Lazarus use Ansi encodings, because that´s the default for Gtk1 and win32 interfaces today. This will change in the future and all widgetsets will support UTF-8, so all applications that pass strings directly to the interface (be written on code or on the object inspector) will need to be converted to utf-8.
When people develop software for non-fully working widgetsets like Gtk 2, Qt, WinCE (and futurely Win32U), they use the IDE compiled for more stable widgetsets, like Gtk and win32. To avoid inconsistencies (like passing iso characters for a utf-8 widgetset), it´s necessary to use an IDE working on the same encoding as the target widgetset. This means that we will need stable UTF-8 IDE before completing the migration to Unicode.
Currently we have various groups of widgetsets, according to the encoding:
Interfaces that use ANSI encoding: win32 and gtk (1) interfaces.
Interfaces that use UTF-8 encoding: gtk (1), gtk2, qt, fpGUI, carbon
Interfaces that currently use ANSI encoding, but need migration to UTF-8: win32, wince
Notice that gtk 1 is on both ANSI and UTF-8 groups. That´s because the encoding is controlled by an environment variable on Gtk 1.
As Lazarus is today, existing software will work, if recompiled for win32, wince or gtk interfaces, but will face encoding issues compiling for other widgetset. And new software, using UTF-8 will work when recompiled for any of the widgetsets on the Unicode group.
One very important note is that you must use the IDE compiled for the same group you are targeting. This is because the IDE uses the encoding of the widgetset it was compiled to, and not the one of the target widgetset to write LFM and LRS files.
Comme vous je suppose -puisque vous formulez un comparatif pour les 2 OS-, je développe toutes mes applications dans les 2 environnements (Win et Nux) systématiquement sinon j'utiliserais Delphi ou pourquoi pas Windev. Et je constate régulièrement que certains composants gère mal nativement l'UTF8 (notamment quand je les fais fonctionner sous Nux) tout simplement parce qu'ils ont été développés sous Windows... On en a maintes fois parlé sur ce forum...
Je rappelle simplement que reproduire et utiliser les propos de quelqu'un nécessite un minimum de bonne foi.
Pour les bases de données, celles que je "rencontre" sont hébergées sur des serveurs qui ne sont pas réglés à ma "sauce" ou (/et) pas nécessairement par défaut et dont fréquemment je n'ai pas le choix de la version. Aussi dois-je m'adapter aux configurations de ceux-ci (ie des serveurs). Là, il faudrait confronter nos problèmes respectifs (enfin les miens -et ceux qui foisonnent sur les forums C++, Lazarus...- et les "non-vôtres"), prendre le temps d'analyser vos propos et tester. Mais franchement, j'aime travailler en toute confiance et en toute "tranquillité". Donc j'en resterai là, "rassuré". On ne va pas se fâcher. Comme pour les StringGrids en 0.9.28, il n'y a aucun problème, c'est-à-dire par exemple que des choses comme l'interclassement pour la connexion mySQL n'ont aucune incidence...euh... sans doute parce que Lazarus gère nativement l'UTF8... C'est finalement très facile !
Néanmoins cordialement. Gilles
:D