Gestinux Forum

Bonjour,
Tout d'abords merci et bravo pour ce bel outil. Je viens d'installer la version "install_gestinux_1.4-stable-5_Debian_x86_64bits.deb" sur ma Mint 19.2. En lien avec mes développements personnels et professionnels, j'utilise mySQL-8.0. Lors de la création de la première base de donnée via gestinux j'ai obtenu l'erreur bloquante et le message suivant. Cette erreur stop la création de la base de donnée.
----
Impossible de créer la table Contacts
SQL Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'Function VARCHAR(35) NULL,
EMail VARCHAR(35) NULL,
Phone VARCHAR(35) NUL' at line 7
CREATE TABLE Contacts(
Id INTEGER AUTO_INCREMENT NOT NULL,
ContactTitleId INTEGER NULL,
FirstName VARCHAR(35) NULL,
MiddleName VARCHAR(35) NULL,
LastName VARCHAR(35) NULL,
Function VARCHAR(35) NULL,
EMail VARCHAR(35) NULL,
Phone VARCHAR(35) NULL,
Fax VARCHAR(35) NULL,
MobilePhone VARCHAR(35) NULL,
UpdateDate DATETIME NULL,
UpdateUser VARCHAR(40) NULL,
PRIMARY KEY (Id),
CONSTRAINT Contacts_C1 FOREIGN KEY (ContactTitleId) REFERENCES ContactTitles (Id) ON DELETE RESTRICT ON UPDATE RESTRICT )
DEFAULT CHARSET=utf8 ENGINE=InnoDB
----
Après quelques tests dans via mon terminal SQL il s'avère que le nom de champ "Function" n'est pas/plus utilisable. Un simple changement de syntaxe vers 'Functions' (pour conserver l'anglais) ou vers 'Fonction' fonctionne. En construisant ainsi la table 'Contacts' à la main, la connexion de Gestiunx à la base de donnée fonctionne, mais la table 'Articles' (qui doit être créée après la table Contacts ) n'est pas accessible et rend l'utilisation de gestinux très limité. Avez vous déjà rencontré ce problème. Serait-il fixable rapidement en remplaçant la dénomination du champ 'Function' ?
Merci d'avance.

Bonjour et merci pour ce retour !

Je n'avais pas encore essayé avec MySql 8...

D'abord, n'existe-t-il pas un paramètre de configuration dans MySql 8 qui permettrait de désactiver le mot clé Function. Le cas échéant, on peut le passer à Gestinux dans la configuration de la base.

Sinon, pouvez-vous regarder si on ne peut pas garder le nom du champ en l'entourant de guillemets, cela pourrait être une solution, avec sans doute quand même des modifications à faire dans Gestinux.

Sinon, il faut donc changer le nom du champ en "Functions", et ce n'est pas simple.

D'abord, la version 1.4 est stable depuis près de 2 ans, il est ennuyeux et toujours risqué de la modifier maintenant.

D'ailleurs, si vous n'avez pas encore de base installée en production, je vous suggère plutôt d'utiliser la version 1.5-release candidate.

Normalement, et par principe, pour assurer une compatibilité ascendante et descendante entre versions, changer le nom d'un champ dans Gestinux nécessite d'en créer un nouveau, de récupérer la valeur de l'ancien champ "Function" lors de l'upgrade, et de ne supprimer ce dernier que dans la version suivante. Donc, dans ce cas particulier, cela empêcherait d'utiliser MySql 8 avant la version suivant la 1.5, c'est à dire pas avant au moins 1 an.

Je n'ai pas envie de déroger à ce principe, et de créer potentiellement des problèmes sur une version stable ou avec des versions de SGBD plus anciennes et bien testés, donc, non, ce ne sera pas fait rapidement...

En attendant, avez-vous absolument besoin de MySql 8 ?
Il n'y a pas ce problème avec MariaDb 10 qui en outre est véritablement libre, alors que MySql tend à ne plus l'être, étant propriété d'Oracle.

Sinon, si vous pouvez compiler, une autre solution serait de faire un fork temporaire pour que le nom du champ dépende d'une directive ou de la version de MySql si on peut la récupérer.

Re
Merci pour ce retour rapide !! Je suis tout à fait d'accord avec vous concernant la rétro-compatibilté des versions. Je pense que je vais faire une installation de MariaDB pour commencer et voir en fonction