Erreur à la sauvegarde d'un nombre à la limite de la taille maximum de chiffre

Bonjour,

Lors de la saisie max d’un nombre à la création d’un objet (Exemple : longueur : 11, saisie : “99999999999”, une série de 11 chiffre 9) Il y a une erreur à l’enregistrement mais si l’objet a un workflow, les boutons de transition d’état et de formulaire apparaissent.

Simplicité version : 4.0 patch level P25
Built on2021-04-08 00:30

Reproductible sur Mysql et PostGreSql et aussi dans la démo lors de la création d’une commande avec une quantité “99999999999”

Le type Simplicité “Entier” induit un type bigint en base de données. Les valeurs min/max de ce type dépendent de la base et de la version de la base de données.

Pour les grand nombres il vaut mieux utiliser le type “big decimal” (avec une précision à 0 si on parle de valeur entières)

A vérifier car un BIGINT signé c’est 2^63 donc ça devrait rentrer largement.
A mon avis Simplicité génère un INT trop petit en base, il faudrait tester la longueur du champ pour choisir INT (size<10) ou BIGINT (size>9).

https://dev.mysql.com/doc/refman/8.0/en/integer-types.html

En attendant faites un ALTER en BIGINT de votre colonne.

Dans le code Simplicité c’est bien des bigint qui sont générés en base avec la version 4.0 actuelle. Je ne me rappelle plus mais à une époque ça générait peut être un integer. Peut être que vos tables datent de cette époque, auquel cas vous devez effectivement faire les alter manuellement sur les colonnes en question.

Je confirme c’est passé de INT à BIGINT par défaut depuis 4 ans d’après les archives GIT.
Il faut donc prévoir un patch d’ALTER sur vos colonnes restées en INT.

J’ai le même probleme pour les décimal(100,32), une idée ?

Il faut regarder le type physique en base ?

Ca a peut être été généré il y a longtemps avec un simple float/double.

Pour un big decimal, Simplicité génère à date :

  • decimal(size, prec)
  • ou numeric(size, prec) sur une base postgreSQL

mais pour MySQL il y a une limitation à 65 :

  • decimal(Math.min(size,65),prec)

Peut on savoir ce qui est stocké dans un num(100,32) ?

Sur postgreSQL, mon champ décimal (100,32) est le suivant :
pra_montant | numeric(30,2)

Il n’y a pas de problème pour renseigner un bigint/decimal, exemple sur la démo en agrandissant les champs à (30,2) :

image

Par contre il doit y avoir un soucis sur la UI avec un rendering monétaire (avec des séparateurs de millier) car l’input a un maxlength=30 trop petit, du coup pour saisir une grosse valeur, il faut tout saisir sans les espaces.

Le maxlength n’a pas trop de sens quand il y a un formattage, on va devoir le retirer sur les champs numériques.

D’autant plus qu’on peut se servir du champ de saisie comme d’une calculette avec un “=”, du style
=123*1.2 + enter
ou utiliser les méthode Math car c’est un eval qui fait le calcul.
bref le maxlength date d’un autre âge…

Bonjour,
Vous regarder ce point ou je dois faire une modification de notre coté ?
Cordialement,

De notre côté, on a juste retiré le “maxlength” sur l’input front pour autoriser le rendering à dépasser + la calculette en CLI (à voir si ça a été poussé par @David).
Du tien, il faut juste vérifier en base que les colonnes ont le bon type (numeric ou bigint).
Si tu constates d’autres problèmes, retourne nous les logs.

Oui ça a été poussé sur la 4.0 maintenance et sur la 5.0.39

merci, j upgrade et je vous tiens au courant.

Reproduit sur la version Simplicité version4.0 patch level P25 Built on 2021-04-14 00:00

Ci dessous les logs :

2021-04-14 10:42:24,810 ERROR [com.simplicite.util.engine.ObjectManager] SIMPLICITE|https://XXXXXXXXXX.io:10953||ECOREDB001|system|com.simplicite.util.engine.ObjectManager|create||Erreur SQL requête: Create failed for object PnfRemboursementAnticipe and row ID = 53
org.postgresql.util.PSQLException: ERROR: numeric field overflow
Detail: A field with precision 30, scale 2 must round to an absolute value less than 10^28.
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2553)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2285)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:323)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:481)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:401)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:164)
at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:130)
at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
at com.simplicite.util.engine.DBAccess.update(DBAccess.java:1716)
at com.simplicite.util.engine.ObjectManager.create(ObjectManager.java:1880)
at com.simplicite.util.engine.ObjectManager.save(ObjectManager.java:2954)
at com.simplicite.util.ObjectDirect.save(ObjectDirect.java:441)
at com.simplicite.util.ObjectDB.save(ObjectDB.java:1159)
at com.simplicite.util.ObjectDB.save(ObjectDB.java:1146)

Je ne reproduits pas, qu’est ce qui a été saisi exactement ? Il doit y avoir un problème de formattage.

Avec 9999999999999999999999999999,99 ça passe sans pb.

On peut surement améliorer le contrôle du validate de ce type de champ, mais il y aura au final une erreur utilisateur car (30,2) = 28 chiffres virgule 2 décimales.

PostgreSQL est peut être plus compliqué car cherche à arrondir à
10000000000000000000000000000 qui dépasse ?

Suite à nos échanges, le problème a pu être reproduit en création, effectivement les boutons de transition ne devraient pas s’afficher alors qu’une erreur a bloqué le création.

En mise à jour, autre soucis sur les grands nombres, Simplicité tronque la valeur saisie pour forcer l’update ce qui n’est pas idéal non plus car l’utilisateur ne voit pas que ce qu’il a renseigné a été tronqué (comme un texte). Dans ce cas, il faudrait également lui remonter une erreur car tronquer un nombre à son insu n’a pas trop de sens en terme UX.

On va renforcer le contrôle du validate en essayant aussi d’afficher un message plus clair que “Erreur d’enregistrement” pour indiquer la valeur maximale autorisée à l’utilisateur (surement en puissance de 10 vue la taille comme “la valeur doit être inférieure ou égale à 1E28”).

Bonjour,

Est-ce que vous avez pu traiter ce point ?

Cordialement,

Oui, on a renforcé le validate d’un numeric pour éviter de laisser la base remonter une erreur.

Merci, c est ok [solution]

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.