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

[jmpacquet]

Bonjour,
Je suis à la recherche d'une comptabilité en libre pour une petite société. J'ai installé fpc 3.2.0 et lazarus 2.0.12 sur mon portable sous Linux Slackware 14.2 (x86_64). J'ai utilisé svn pour rapatrier les sources et j'essaie d'éxécuter gestinux 1.5 après l'avoir compilé. Le programme se lance bien et affiche une fenêtre nommée GESTINUX: Menu principal avec une mosaïque de 5 sous-fenêtres colorées comportant chacune une arborescence de menu. Un clic sur "A propos de Gestinux" confirme qu'il s'agit de la version 1.5-stable-2.
Quand j'essaie de définir la base de données j'obtiens:
Une erreur imprévue est survenue.
Merci de la signaler en cliquant sur le bouton "Aide".

SQL Error: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1

Le serveur est MariaDB 10.3.11. En regardant avec phpMyAdmin la base gestinux, 2 tables vides ont été créées:Countries et CountryCodes.

[tintinux]

Bonjour

Vous êtes tombé sur un bug bloquant qu'on ne parvient pas à expliquer, seulement à contourner.

Il se produit avec Gestinux 1.5.2 et aussi 1.6, sous Linux (Ubuntu, et donc maintenant aussi Slackware) avec MariaDb 10, mais je n'ai pas assez de retours sur les autres configurations, ce qui aiderait à trouver la cause.

Lors de l'initialisation d'une base de données (ou lors du changement de langue) un fichier texte contenant les pays est lu ligne par ligne, et pour chaque ligne un INSERT ajoute les pays dans une table (temporaire sous 1.5, normale et supprimée ensuite avec 1.6 pour portabilité multi SGBD).

Quand on sélectionne une autre langue que le Français, l'importation des pays se passe bien, sans cette erreur. Si on supprime 3 ou 4 petits états, avant de créer la base dans le fichier français, l'erreur ne survient pas non plus ! (fichier joint) On dirait qu'une certaine séquence de caractères, ou un certain volume de données dans une transaction en serait la cause, mais je ne trouve rien d'évident. Rien dans le code ne peut expliquer le problème.

Une autre gros souci est qu'une erreur apparemment similaire se produit un peu plus loin lors de l'initialisation des Reports.

Les recherches continuent... Toute suggestion ou expérience est la bienvenue.

[jmpacquet]

Merci de la réponse. Je viens d'essayer la version 1.6 avec le fichier fr_FR_countries.txt sans succès.
Hier j'avais réussi à initialiser la base en partant de la version 1.5 du paquet Debian (j'ai tout extrait du paquet et mis les éléments là où ma Slackware les veut) après être tombé sur le bug http://forum.gestinux.net/viewtopic.php?f=8&t=140 . Le problème de ce paramétrage de mysql est qu'il interdit l'utilisation du client mysql en ligne de commande:
~$ mysql -u root -p
mysql: unknown variable 'sql_mode=NO_ENGINE_SUBSTITUTION'

Je ne comprends pas pourquoi j'ai des résultats différents entre la version 1.5 du paquet Debian et cette même 1.5 que je compile dans lazarus.

J'avais une bonne expérience de la programmation Delphi avec la base de données Firebird mais c'était il y a 25 ans. Je vais voir si ça revient...

[tintinux]

Le problème de ce paramétrage de mysql est qu'il interdit l'utilisation du client mysql en ligne de commande:

Code: Select all

~$ mysql -u root -p
mysql: unknown variable 'sql_mode=NO_ENGINE_SUBSTITUTION'

Pour ce problème, si le client et le serveur sont sur la même machine, il faut mettre la clause dans la section [server] et non [client-server]
J'ai modifié les messages à ce sujet.

[jmpacquet]

Comme j'étais dans les essais et que c'est disponible sur mon portable, j'ai essayé PostgreSQL 10.10 avec la version 1.5 Debian de gestinux (celle qui marche avec MariaDB 10.3), sans succès:

Une requête dans la base de données a échoué.
Veuillez copier et conserver le message ci-dessous, puis suivre les indications dans la page d'aide.

SQL Error: ERROR: syntax error at or near "SELECT"
LINE 1: CREATE TEMPORARY TABLE TempCountries SELECT Count...
^

L'erreur est au même endroit qu'avec MariaDB: juste après la création des 2 tables countries et countrycodes.

Si j'essaie avec la version 1.6 sous lazarus, j'ai un message comme quoi il ne trouve pas le driver!

[antoineL]

Si on supprime 3 ou 4 petits états, avant de créer la base dans le fichier français, l'erreur ne survient pas non plus ! (fichier joint)

Ah ! C'est donc pour cela que dans la révision r2088 tu as supprimé les îles Caïmanes ! Désolé donc de les avoir remises dans la r2093

Il se produit avec Gestinux 1.5.2 et aussi 1.6, sous Linux (Ubuntu, et donc maintenant aussi Slackware) avec MariaDb 10, mais je n'ai pas assez de retours sur les autres configurations, ce qui aiderait à trouver la cause.

Une des principales différences entre Linux et Windows, c'est que dans le premier cas on utilise une version très récente (car mise-à-jour) du pilote côté client, tandis que dans le deuxième on utilise généralement une version très ancienne (dans le cas de Gestinux, une version 5.1.47 de MySQL qui date de mai 2010.) Ceci pourrait expliquer cela. Cependant, je viens de faire le test sous Windows en utilisant comme client des libmariadb.dll récentes (10.5.8 en x64 et 10.4.12 en x86, en l'occurrence celle de HeidiSQL) et si je ne vois pas de souci avec ma version de développement 1.6/x64, en x86 avec la version stable de référence 1.5-1 (de SourceForge) plus le fichier fr_FR_countries.txt de la 1.5-2 (r2067), j'ai une erreur

Code: Select all

Vous ne pouvez pas créer une nouvelle base de données sur ce serveur. (SQL Error: Data too long for column 'CountryCode' at row 1)

Et là, je sais où est le souci: il y a des caractères parasites dans les révisions 2067-2069 pour le Soudan du Sud (et aussi dans le fichier qu'a envoyé Tintinux ce matin), problème qui a été corrigé dans la révision r2072 pour trunk, mais jamais reporté dans la branche 1.5.

Je ne sais pas si c'est le problème que voit jmpacquet (en dehors du fait que le message est beaucoup plus explicite).

Sinon je me souviens avoir eu des soucis avec les premières révisions de la 1.6, quand je changeai assez souvent de langue, et j'avais remarqué que cela bloquait en passant au français. À 'époque j'avais déterminé un contournement (différent de celui de Tintinux): comme le problème ne se posait pas en espagnol, je ne faisait plus de vérification de structure en français Et je ne me suis plus posé de question. Mais je ne sais pas si ma version actuelle de développement a le problème avec Linux, car je n'ai pas encore réussi à mettre en place la compilation (croisée ou pas) pour Linux... J'y travaille...

Rien dans le code ne peut expliquer le problème.

Je concours. Cependant j'ai trouvé deux détails (qui n'ont probablement rien à voir) dans le code: d'abord ligne 289 de unitcheckdatabase.pas dans la 1.5, ou
182 pour trunk, dans ImportCountriesFile, il y a une instruction SplashClose(), vestige du code de la version 1.4, qui ne devrait plus être là. Et uniquement pour la 1.6, ligne 172, je pense que le Trim() devrait être à l'intérieur du StringSql(). Comme annoncé, je ne pense pas que ce soit le problème.

[antoineL]

j'ai essayé PostgreSQL 10.10 avec la version 1.5 Debian de gestinux (celle qui marche avec MariaDB 10.3), sans succès

Oui, c'est un problème connu. Je travaille pour essayer de le résoudre, mais je n'ai pas assez de ressource disponible (et je suis un peu comme toi, cela fait 32 ans que je ne programme plus régulièrement en Pascal, et cela revient très doucement !)

Antoine

[tintinux]

Bonjour

Je crois que la priorité est de refaire marcher la distribution 1.5, en réglant les deux bogues rencontrés lors de l'initialisation d'une base :

1. le plantage en important des pays français. (enlever les 4 premières "Iles" fait disparaître le bug)
2. le plantage, ensuite, en important une définition d' AccountingExport (supprimer le fichier fait disparaître le bug)

Je suis persuadé que ça vient de données erronées ou parasites dans les 2 fichiers importés, mais je n'arrive pas à trouver lesquelles.
Il n'y a aucune raison de suspecter le code ni de le recompiler, puisqu'il fonctionnait bien il y a quelques mois quand la version a été livrée.
Et donc, pas besoin d'être un crack en Pascal !
Il faut surtout avoir un bon éditeur de texte, j'ai peur que ceux que j'utilise (Ubuntu Gedit, ou celui de Lazarus) ne permettent pas de voir le problème.

Je vais essayer de creuser encore mais, Antoine, si tu vois quelque chose, n'hésite pas !

Par ailleurs, et pour info, j'ai supprimé la nécessité de la clause NO_ENGINE_SUBSTITUTION en reprenant le code de la 1.6. Ce qui prouve au moins que ce n'est pas cette clause qui cause les soucis. Je vais bientôt livrer les sources.

Merci pour votre aide !

[tintinux]

problème qui a été corrigé dans la révision r2072 pour trunk

Je n'avais pas vu ça...
Tu peux mettre le bon fichier sur la version 1.5 ?

Et vois-tu quelque chose dans le AccountingExport.ini ?

[antoineL]

Tu peux mettre le bon fichier sur la version 1.5 ?

Fait, révision 2105.

Et vois-tu quelque chose dans le AccountingExport.ini ?

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). De plus le texte de la requête FR_Verif_FEC.sql a lui aussi des voyelles accentuées en UTF-8 sans BOM.
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.
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.

• 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

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).

Pour moi tout cela devrait fonctionner (et de fait, je n'ai jamais eu de blocage sur mes systèmes à ce niveau).