Discussion :

[Mick16]

Bonjour,

J'ai un projet sous WinDev 16, une base de données MySQL (utf8).

De temps en temps, lorsque j'enregistre les données dans la base, les mots accentués sont "convertis" en une chaîne informe !

un "é" va devenir "ƒâ€šÃ‚©" par exemple.


Je ne sais plus où chercher... Merci d'avance !

[Lo²]

Salut,

Il existe pas mal de fonction de conversion de chaîne traitant de l'UTF8 dans l'aide

[Mick16]

Merci pour ta réponse.

Tu me suggères d'utiliser UTF8VersChaîne à chaque chargement dans l'appli et ChaîneVersUTF8 à chaque enregistrement dans la base ?

N'y a-t-il pas quelque chose de plus global ?

Je vois qu'il y a des options dans le descriptif de projet :

[Lo²]

Je ne te suggère rien, c'était une indication.

Je ne connais pas ton besoin réel et je ne connaissais pas ce paramètre au niveau du projet

[Mick16]

Merci quand même

J'espère que quelqu'un d'autre aura une nouvelle idée...

[Lo²]

Une question quand même :
Pourquoi ta base est en utf8 ?

[Mick16]

Je n'ai pas de réponse pertinente à cette question, ça m'a fortement été suggéré.

Des problèmes entre l'utf8 et Windev ?

[Lo²]

non pas d'incompatibilité mais windev est un AGL basé sur le monde windows et donc cp1252.

L'intérêt de l'UTF8, à mon avis, c'est lorsque qu'une appli est multi-plateforme, car le charset UTF8 est le plus utilisé.

Si on sait que l'on va tourner sur des PCs avec Windows dessus, autant éviter les problèmes de charset à gérer.

[Narwe]

L'UTF8 est pratique si l'application est multilangue (avec des langues utilisé autre chose qu'un alphabet latin).

La base est en UTF8 mais il faut aussi vérifié que les tables et le champ des tables le son (une base en UTF8 signifie que par défaut, ça sera de l'UTF8 mais on peut forcer autre chose).

Il faudrait savoir comment se fait la connexion à la base. Est-ce un HOuvreConnexion ?
Si c'est le cas, personnellement, je rajoute un "WD Unicode Support = 1" (c'est vrai qu'il s'agit de la valeur par défaut, donc normalement inutile) (voir ici http://doc.pcsoft.fr/fr-FR/?9000124&...lles_connexion)
A noter, je fais cela sur WD15.

En indiquant que le problème se déroule de temps en temps, il faudrait trouver les cas où cela se produit. Est-ce une table en particulier (dans ce cas, regarder si cette table et ces champs sont bien en UTF8) ? Est-ce un traitement en particulier (peut-être y-a-t-il un appel à une fonction qui change l'écriture dans la base, peut-être est-ce le champ de la fenêtre Windev qui est particulier (UNICODE cochée)) ?

[Mick16]

non pas d'incompatibilité mais windev est un AGL basé sur le monde windows et donc cp1252.

L'intérêt de l'UTF8, à mon avis, c'est lorsque qu'une appli est multi-plateforme, car le charset UTF8 est le plus utilisé.

Si on sait que l'on va tourner sur des PCs avec Windows dessus, autant éviter les problèmes de charset à gérer.

Ce client n'utilise l'application qu'en Français, l'utf8 n'était pas nécessaire...

[Mick16]

L'UTF8 est pratique si l'application est multilangue (avec des langues utilisé autre chose qu'un alphabet latin).

La base est en UTF8 mais il faut aussi vérifié que les tables et le champ des tables le son (une base en UTF8 signifie que par défaut, ça sera de l'UTF8 mais on peut forcer autre chose).

Il faudrait savoir comment se fait la connexion à la base. Est-ce un HOuvreConnexion ?
Si c'est le cas, personnellement, je rajoute un "WD Unicode Support = 1" (c'est vrai qu'il s'agit de la valeur par défaut, donc normalement inutile) (voir ici http://doc.pcsoft.fr/fr-FR/?9000124&...lles_connexion)
A noter, je fais cela sur WD15.

En indiquant que le problème se déroule de temps en temps, il faudrait trouver les cas où cela se produit. Est-ce une table en particulier (dans ce cas, regarder si cette table et ces champs sont bien en UTF8) ? Est-ce un traitement en particulier (peut-être y-a-t-il un appel à une fonction qui change l'écriture dans la base, peut-être est-ce le champ de la fenêtre Windev qui est particulier (UNICODE cochée)) ?

Merci pour ta réponse.

L'appli est en Français, les données aussi.

La base est en latin1 mais les tables en utf8 !

La connexion se fait comme suit :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
SI HDécritConnexion(Connexion:lenom(),Connexion:lelogin(),Connexion:lemdp(),Connexion:laIP(),Connexion:laBase(),hAccèsNatifMySQL,hOLectureEcriture) ALORS
	SI PAS HOuvreConnexion(Connexion:m_sNom) ALORS
		Erreur("Connexion à la base impossible.")
		Connexion:m_sNom=""
	FIN
SINON
	Erreur("Connexion à la base impossible.")
	Connexion:m_sNom=""
FIN

Le problème ne se produit que sur une fenêtre : ce sont 2 tables remplies par programmation (HExecuteRequete + Parcours + TableAjouteLigne).
Les colonnes en question ont "unicode" décoché.


Je vérifie le reste...

[Mick16]

Les tables problématiques sont en utf8.

Les champs sont presque tous sans "collation".
Dans une des deux tables, quelques champs sont toujours en "latin1_swedish_ci".

Je trouve bizarre que les requêtes soient exécutées comme suit :

Code :

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

1
2
3
4
5
6
7
8
 
// Chargement de la table problématique n° 1
HExécuteRequête(REQ1,"SERV_HF",hRequêteSansCorrection,nIDDocument)
 
// et
 
// Chargement de la table problématique n° 2
HExécuteRequête(REQ2,hRequêteDéfaut,nIDDocument,nLigne)

"SERV_HF" est le nom de la connexion à l'époque où la base était gérée par Hyperfile, elle n'a pas changé de nom quand on est passé sous MySQL.

Pourquoi ne pas utiliser seulement :

Code :

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

1
2
3
4
5
6
7
8
9
 
REQ1.Param1 = nIDDocument
HExecuteRequete(REQ1)
 
// et
 
REQ2.Param1 = nIDDocument
REQ2.Param2 = nLigne
HExecuteRequete(REQ2)

[Lo²]

Pour la première requête, je comprends l'utilité de cette syntaxe : le mode hRequêteSansCorrection est utilisé car nécessaire lors de l'utilisation d'un accès natif.

Pour la deuxième syntaxe, je ne comprends pourquoi utilisé une syntaxe différente car si un ordre SQL spécifique à MySQL est utilisé, il y a des chances de plantage.

[Mick16]

Pour la première requête, je comprends l'utilité de cette syntaxe : le mode hRequêteSansCorrection est utilisé car nécessaire lors de l'utilisation d'un accès natif.

Pour la deuxième syntaxe, je ne comprends pourquoi utilisé une syntaxe différente car si un ordre SQL spécifique à MySQL est utilisé, il y a des chances de plantage.

Pour ma part, je n'utilise hRequêteSansCorrection qu'avec HExécuteRequêteSQL.

Si j'utilise les requêtes de l'éditeur, je tape HExécuteRequête(MaRequete) et je n'ai pas de problème.

[dsr57]

Bonjour

Je tente de comprendre le problème, tu as une table qui affiche des informations provenant d'une table.
En lecture tu n'as pas de problème pour récupérer le caractère 'é', en revanche quand tu enregistre dans cette table (Insert ou update) depuis cette fenêtre le caractère 'é' devient une liste de caractère ...

• est ce que tu as une analyse reliée à ton projet
• as tu un autre process qui enregistre dans cette table
• les requêtes sont générées avec le générateur ou saisie en SQL

Bon dev

[Narwe]

Il peut aussi être intéressant de voir quel requête d'INSERT ou d'UPDATE reçoit le serveur MySQL.
Pour cela, au niveau du Workbench du serveur MySQL, il faut cocher "General Log" (un peu plus se trouve l'emplacement du fichier généré).
Il faut arrêter et relancer le serveur MySQL pour que le log s'active.

ATTENTION : A ne faire que sur une base de test !!!!

Le log se remplit très vite et on se retrouve rapidement avec un fichier de plusieurs Go (ce qui ralenti l'exécution des requêtes puisque que pour chacune d'entre elle MySQL ecrit dans ce gros fichier.

Il faudrait, comme le dit dsr57, nous indiquer comment son ajouter / modifier les enregistrements dans la base.
Est-ce via des HExecuteRequete, des HExecuteRequeteSQL, des HAjoute ou autre (SQLExec peut-être mais ce serait tordu) ?

Le code d'ouverture de session semble comporter une erreur (de logique tout au moins) :

Code :

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

1
2
SI HDécritConnexion(Connexion:lenom(),Connexion:lelogin(),Connexion:lemdp(),Connexion:laIP(),Connexion:laBase(),hAccèsNatifMySQL,hOLectureEcriture) ALORS
	SI PAS HOuvreConnexion(Connexion:m_sNom) ALORS

La connexion est décrite avec le nom Connexion:lenom() mais ouverte avec Connexion:m_sNom.
On suppose sans trop de mal que la méthode lenom() est un getteur sur m_sNom mais c'est un peu troublant.

[Mick16]

Bonjour

Je tente de comprendre le problème, tu as une table qui affiche des informations provenant d'une table.
En lecture tu n'as pas de problème pour récupérer le caractère 'é', en revanche quand tu enregistre dans cette table (Insert ou update) depuis cette fenêtre le caractère 'é' devient une liste de caractère ...

• est ce que tu as une analyse reliée à ton projet
• as tu un autre process qui enregistre dans cette table
• les requêtes sont générées avec le générateur ou saisie en SQL

Bon dev

Bonjour,

Ce n'est pas exactement ça : je crois enregistrer un "é" et quand je réouvre mon document, j'ai une liste de caractères.

• j'ai une analyse reliée au projet
• j'effectue d'autres enregistrements dans d'autres tables depuis cette même fenêtre
• les requêtes en question ont été créées par le générateur

[Mick16]

Il peut aussi être intéressant de voir quel requête d'INSERT ou d'UPDATE reçoit le serveur MySQL.
Pour cela, au niveau du Workbench du serveur MySQL, il faut cocher "General Log" (un peu plus se trouve l'emplacement du fichier généré).
Il faut arrêter et relancer le serveur MySQL pour que le log s'active.

ATTENTION : A ne faire que sur une base de test !!!!

Le log se remplit très vite et on se retrouve rapidement avec un fichier de plusieurs Go (ce qui ralenti l'exécution des requêtes puisque que pour chacune d'entre elle MySQL ecrit dans ce gros fichier.

Il faudrait, comme le dit dsr57, nous indiquer comment son ajouter / modifier les enregistrements dans la base.
Est-ce via des HExecuteRequete, des HExecuteRequeteSQL, des HAjoute ou autre (SQLExec peut-être mais ce serait tordu) ?

Le code d'ouverture de session semble comporter une erreur (de logique tout au moins) :

Code :

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

1
2
SI HDécritConnexion(Connexion:lenom(),Connexion:lelogin(),Connexion:lemdp(),Connexion:laIP(),Connexion:laBase(),hAccèsNatifMySQL,hOLectureEcriture) ALORS
	SI PAS HOuvreConnexion(Connexion:m_sNom) ALORS

La connexion est décrite avec le nom Connexion:lenom() mais ouverte avec Connexion:m_sNom.
On suppose sans trop de mal que la méthode lenom() est un getteur sur m_sNom mais c'est un peu troublant.

Bonjour,

J'activerai les logs et ferai un essai la nuit prochaine, je serai tranquille !

En ce qui concerne les instructions, j'utilise

• HExécuteRequête pour exécuter la requête
• Hajoute, HModifie pour ajouter/modifier les enregistrements

Quant à l'établissement de la connexion, tu as raison, c'est un peu bizarre mais tu as compris l'esprit.

[dsr57]

Bonjour

Quel est le sous-type de tes colonnes qui posent problème dans l'analyse ?

Bon dev

[Mick16]

Bonjour

Quel est le sous-type de tes colonnes qui posent problème dans l'analyse ?

Bon dev

Bonjour,

Merci pour ta réponse.


Texte > Mémo texte dans l'analyse.

Long text dans MySQL.