Script SQL

[Reefounet]

Bonjour à tous

Voici le script SQL généré par Gestinux de l'export d'une base vide pour PostgreSQL 9.

Le script comporte des erreurs, mais rien d'insurmontable.

/*ERREUR Pas de guillemet pour Function Language ou Tables (Dropt, create, Insert ) */
/*ERREUR mauvaise position guillemet date_format(m.MoveDate, \'%Y%m%d\') À TRANSFORMER EN \'%Y%m%d'\ */
/*ERREUR mauvaise position guillemet date_format(j.CloseDate, \'%Y%m%d %H:%i:%s\') A TRANSFORMER EN \'%Y%m%d %H:%i:%s'\ */

et une autre erreur

mais je n'arrive pas à savoir quoi mettre.

Du coup, je ne peux pas aller plus loin.

[tintinux]

Bonjour

Pour les function Language ou Tables (Drop, Create, Insert ), il faut adapter les procédures spécifiques à PostgreSQL pour suivre la nouvelle syntaxe, ça n'est pas trop compliqué. Il y a peut-être des cas où il faudra créer de nouvelles procédures. Tant qu'on y est, ce serait bien d'isoler tout ce qui est spécifique à un SGBD dans des unités (p. ex : GdbConnexion_pgsql).

Je te propose d'ignorer pour l'instant le remplissage de la table (Queries) qui contient notamment un script assez complexe permettant de sortir un export "FEC" requis par l'administration. Je suis quand même très surpris de la différence de syntaxe entre MySQL et PostgreSQL. On y reviendra quand tu auras avancé, ça n'est pas essentiel.

[Reefounet]

Rebonjour,

@Tintinux
Je pense qu'il y a une erreur dans la génération du fichier Sql et du coup je suis un peu coincé.
En effet, par endroit, les noms des tables sont encadrés de caractères bizarres comme celui ci : `
Je pensais à tord que c'était des simples guillemets mais en fait non.
Exemple ligne 1089

Ces caractères n'ont pas lieu d'être et provoquent une perturbation avec les simples guillemets et avec les noms des tables, qui dans les instructions Insert, ne sont pas entourés de caractères. (Sql pour MySQL et Postgres).
Peux-tu modifier cela et me renvoyer le fichier Sql afin de le valider.
Merci d'avance.

[tintinux]

Ce n'est pas une erreur, ce sont des guillemets qui étaient demandés par d'anciennes versions de PostgreSQL et sont encore acceptés aujourd'hui par MySql et MariaDb, mais plus par PostgreSQL qui a donc provoqué une rupture de compatibilité.

Dans la mesure où les noms des tables Gestinux ne contiennent jamais d'espace, on peut supprimer les guillemets dans cet export, ce que je vais faire.

En attendant de commiter, je joins le nouvel export avec cette modification.

NB : Il y a un cas, dans les imports, où il est théoriquement possible de lire des tables externes dont le nom pourrait contenir des espaces et donc nécessiter des guillemets. Il faudra voir, plus tard, quel type de guillemet est admis par PostgreSQL.

[Reefounet]

Merci, je regarde ça ce soir.

[Reefounet]

Bonjour à tous,

Concernant le script SQl :

Ligne 108 et 110, il faut enlever les guillemets, c'est une instruction propre à Postgresql, elle n'a pas d'équivalent en SQL.

Code: Select all

DROP LANGUAGE IF EXISTS plpgsql;

CREATE LANGUAGE plpgsql;

Ensuite, et je ne sais pour quelle raison (pour le moment) mais il ne m'accepte pas les \' ou \" . Il faut donc les remplacer par '' ou "" , ce qui est plus conforme à la norme SQL voir lien https://docs.postgresql.fr/18/sql-synta ... GS-UESCAPE.
Ensuite tout s'importe bien.

J'ai donc pu enfin regarder un peu Gestinux.
D'abord, Bravo, il y a eu beaucoup de travail.
Mais, je n'ai pas pu aller bien loin car j'ai une erreur à la création d'un article

Code: Select all

Une erreur imprévue est survenue.
Merci de la signaler en cliquant sur le bouton "Aide".

 SQL Error: ERROR:  column "pst.id" must appear in the GROUP BY clause or be used in an aggregate function
LIGNE 1 : ...ucts psp ON psp.Id = ps.productid UNION SELECT 1, pst.id, NU...
                                                               ^
ERROR 42803
column "pst.id" must appear in the GROUP BY clause or be used in an aggregate function
position: 383 
Code: 7 SQL: SELECT 0 AS Footer, ps.id, wh.id AS WarehouseId, wh.name AS WarehouseName, ps.qty_checked, ps.date_checked, ps.qty_quoted, ps.qty_ordered, ps.qty_delivered, qty_checked-COALESCE(ps.qty_delivered,0) AS qty_remaining, ps.updatedate FROM Warehouses wh LEFT JOIN ProductsStocks ps ON ps.warehouseid=wh.id AND ps.ProductId = $1 JOIN Products psp ON psp.Id = ps.productid UNION SELECT 1, pst.id, NULL AS WarehouseId, '*' AS WarehouseName, SUM(pst.qty_checked) AS qty_checked, NULL AS date_checked, SUM(COALESCE(pst.qty_quoted,0)) AS qty_quoted, SUM(COALESCE(pst.qty_ordered,0)) AS qty_ordered, SUM(COALESCE(pst.qty_delivered,0)) AS qty_delivered, SUM(pst.qty_checked)-SUM(COALESCE(pst.qty_delivered,0)) AS qty_remaining, MAX(pst.updatedate) AS updatedate FROM ProductsStocks pst WHERE pst.productid = $1 ORDER BY 1,4

Une idée ?

Bonne journée à tous

[tintinux]

Bonjour,

J'ai livré des sources pour enlever les guillemets qui ne plaisent pas.

J'en ai profité pour corriger la numérotation des instructions qui était erronée pour PostgreSQL. Il reste un problème (pour tous les SGBD) dans la numérotation des créations d'index. C'est seulement en commentaire et ce n'est pas bloquant.

La version affichée pour PostgreSQL sera la 14, puisque c'est celle que tu utilises. Des tests avec la 16 seraient cependant utiles...

Pour le problème en création d'article, c'est un autre sujet à créer. Il faut trouver la requête SQL équivalente qui fonctionne avec les 2 SGBD. Si c'est impossible, il faudra décomposer en plusieurs requêtes compatibles. Cela va peut-être survenir ailleurs.

Pour les requêtes stockées dans la base, regarde si en remplaçant dans le fichier antislash-simple quote par deux simple quotes cela plaît mieux à PostgreSQL. C'est accepté par MariaDb et j'espère aussi par MySql.

[Reefounet]

J'ai livré des sources pour enlever les guillemets qui ne plaisent pas.

La version affichée pour PostgreSQL sera la 14, puisque c'est celle que tu utilises. Des tests avec la 16 seraient cependant utiles...

Tu peux mettre >14 car j'ai monté une petite machine de test avec Postgresql 16 et les accès fonctionnent bien.

Pour les requêtes stockées dans la base, regarde si en remplaçant dans le fichier antislash-simple quote par deux simple quotes cela plaît mieux à PostgreSQL. C'est accepté par MariaDb et j'espère aussi par MySql.

C'est accepté par Postgresql car c'est plus dans la norme Sql. C'est d'ailleurs ce que j'ai modifié dans le fichier Sql d'importation.