"error in your SQL syntax" en créant une base de données

Si vous voulez participer au développement de Gestinux, et que vous ne maîtrisez pas l'anglais, écrivez vos questions ou remarques ici.

Il reste préférable, dans la mesure du possible, d'utiliser le forum anglais.
tintinux
Site Admin
Posts: 169
Joined: 21 Jun 2012, 19:07
Location: Blois (France)
Contact:

Re: "error in your SQL syntax" en créant une base de données

Post by tintinux »

Il y a un truc qui pourrait (mais ne devrait pas) poser problème: le fichier AccountingExport/FR_default.ini est en codage UTF-8 avec des caractères non-ASCII7 sans BOM, mais le jeu de caractères spécifié dans l'exportation est 8859-1 (je sais, cela n'a rien à voir, mais bon, je signale).
C'est normal, les fichiers de paramètres (et tous les sources de Gestinux) sont en UTF-8, mais ils peuvent servir à produire du 8859-1 parce que c'est ce qu'exige la norme FEC.
De plus le texte de la requête FR_Verif_FEC.sql a lui aussi des voyelles accentuées en UTF-8 sans BOM.
Je ne vois pas pourquoi ça poserait problème... Ou alors seulement si le jeu de caractères est forcé à autre chose que UTF-8...
Et il y a là un effet que je n'avais jamais remarqué jusqu'à aujourd'hui: dans la base MySQL normale, ces voyelles accentués m'apparaissent comme si je lisait du code UTF-8 en codage 8859-1 («Présentation par défaut»; ou «/* Liste des journaux non clôturés avant la fin de période»). Cet effet n'apparaît pas dans les autres tables comme par exemple Accounts, donc je pense voir du surcodage dans Queries, ReportLayouts et ReportDefinitions.
Pas normal, on devrait avoir simplement de l'UTF-8 et l'afficher comme tel.
Peut-être qu'effectivement un surcodage a été involontairement effectué à un moment donné...
Je vais chercher dans cette direction et comparer les versions...
Je suis sur une machine Windows et je regarde à travers HeidiSQL, donc 8859-1 (ou UTF-16, cela revient au même) est le codage système par défaut, et les bases en question utilise 'utf8' comme default_character_set_name ; je ne sais pas si sur une machine Linux avec UTF-8 par défaut partout cela bloque quelque part, ou même quel est le comportement exact au niveau du protocole MySQL/MariaDB (nouvelles versions, mises-à-jour ?) entre client et serveur.
A une époque je passais souvent de Linux (avec différents clients SQL) à Windows (avec HeidiSQL) et réciproquement, et je n'ai jamais eu de problème avec l'UTF-8. Je suis ensuite passé à SquirrelSQL pour avoir le même outil sur les 2 systèmes. Aujourd'hui j'ai plus de machine ni de licence Windows, donc je sais pas.
Par contre, pour information, UTF-16 n'est pas du tout la même chose que 8859. Dans le premier, un caractère affiché est codé avec 2 ou 4 octets (et c'est volumineux), et dans l'autre un caractère affiché est codé avec toujours un seul octet (et on ne peut pas tout coder).
Update: j'ai une autre base avec 'latin1' comme default_character_set_name. Et là j'observe une différence : si pour la table Queries j'ai encore le surcodage, je ne le vois plus dans ReportLayouts et ReportDefinitions. Le fait que ce soit différent entre les tables (qui sont mises à jour en même temps lors de la reconstruction) indique que ce n'est pas un problème de paramétrage client qui pourrait avoir changé. Comme reports/AccountingExport met à jour Queries, je pense qu'il faut aller voir de ce côté (et comme mesure temporaire de contournement, supprimer les voyelles accentuées de AccountingExport/*sql).
/Update
Si, je crains qu'un mauvais paramétrage client d'un utilitaire à un moment donné ait provoqué l'enregistrement d'un mauvais codage de certains fichiers, qui ont été ensuite remontés dans SVN, alors que d'autres fichiers eux n'ont pas été changés.
Autre détail normalement sans importance qui attire mon attention: AccountingExport/FR_Export_FEC.mysql est encodé avec des fins de lignes CR+LF (tous les autres de l'arborescence reports/, à l'exception de "BalanceSheet/FR_Bilan 2033A.{ini,lrf}" et "BalanceSheet/FR_Resultat 2033B.ini", ont des terminaisons LF seulement).
Je crois que c'est sans importance, ça.
Pour moi tout cela devrait fonctionner (et de fait, je n'ai jamais eu de blocage sur mes systèmes à ce niveau).
Tu veux dire que tu peux créer une société sans erreur (après avoir sélectionné la langue FR) ? Avec 1.5 ou trunk ?
Cordialement,

Tintinux
antoineL
Posts: 27
Joined: 22 Jan 2021, 19:40
Location: Comunitat valenciana

Re: "error in your SQL syntax" en créant une base de données

Post by antoineL »

tintinux wrote: 09 Dec 2021, 19:46Tu veux dire que tu peux créer une société sans erreur (après avoir sélectionné la langue FR) ? Avec 1.5 ou trunk ?
Mardi, avec Gestinux Windows en version 1.5.1 publiée (x86 donc) et une version 1.6 ayant plusieurs différences avec trunk en x64 (c'est ce que j'avais sous la main), des clients MariaDB récents et un serveur MariaDB Win64 10.5.8 j'ai réussit à créer des bases avec langue fr_FR sans blocage.
Sauf pour le problème du fichier language/fr_FR_countries.txt en 1.5, mais cela c'est un problème identifié et qui devrait être résolu.

Je n'ai pas encore eu le temps de compiler Gestinux pour Linux, ni de tester client Windows contre serveur Linux (ou vice-versa) ni de recompiler trunk. Mais cela approche à grands pas.
Post Reply