Lors de la synchronisation des articles avec Exact Online, nous rencontrons l’erreur suivante :
itgenxml091
La colonne ‘BARCODE’ a une valeur ‘10788942212008112505’ qui ne peut pas être convertie au type de données Int64.
La valeur ‘10788942212008112505’ n’est pas un nombre entier valide.
La valeur était soit trop grande, soit trop petite pour un Int64.
Utilisez la virgule “,” comme séparateur des milliers.
ID de la requête : 0HNN7G8UUIJP0:00000001
Cela provoque l’échec de la synchronisation.
Pourrait-on vérifier pourquoi le champ BARCODE est traité comme un Int64 au lieu d’un texte (string) ?
La cause est une valeur possible trop grande pour le type de données utilisé pour ce champ dans le logiciel Invantive. Une modification sera apportée pour résoudre ce problème.
Rapport : gmr-eol-items
Pile d’appels :
System.OverflowException
ValidationException
ValidationException
at System.Number.ThrowOverflowException[TInteger]()
at System.String.System.IConvertible.ToInt64(IFormatProvider provider)
at Invantive.Data.DataUtility.ConvertToLong(GlobalState owner, ExecutionOptions executionOptions, Object val)
Requête SQL :
select /*+ result_set_name('Items') */
...
, itm.barcode
...
from ( select to_number(itm.division_code) division
, to_guid(replace(itm.id_attr, '{', '', '}', '')) id
, itm.*
from exactonlinexml..items@eol itm
) itm
...
Exact Online dicte dans les métadonnées qu’il s’agit d’un nombre entier :
La plus grande valeur d’entrée possible dans l’interface utilisateur d’Exact Online elle-même est composée de 20 neuf :
99999999999999999999
Le nombre 10788942212008112505 a 20 chiffres, et est plus grand que la valeur maximale avec 19 chiffres d’un Int64 (9223372036854775807).
Dans les API REST, Exact Online utilise une chaîne de texte au lieu d’un Int64 comme pour XML. Un texte est également préférable en raison des zéros précédant éventuellement le nombre.