Tijdens de synchronisatie van Items naar Exact Online krijgen wij onderstaande fout:
itgenxml091
The column ‘BARCODE’ has a value ‘10788942212008112505’ which cannot be converted to the data type Int64.
De waarde ‘10788942212008112505’ is geen geldig groot geheel getal.
Value was either too large or too small for an Int64.
Gebruik komma ‘,’ als scheidingsteken voor duizendtallen.
Request ID: 0HNN7G8UUIJP0:00000001
Hierdoor mislukt de synchronisatie.
Kan nagekeken worden waarom het BARCODE-veld als Int64 wordt behandeld in plaats van als tekst (string)?
Oorzaak is een te grote mogelijke waarde voor het gebruikte data type voor dit veld in de Invantive software. Een aanpassing zal gemaakt worden om dit probleem op te lossen.
Rapport: gmr-eol-items
Call stack:
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)
SQL Statement:
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 dicteert in de metadata dat het een integer-getal is:
De grootst mogelijke invoerwaarde in Exact Online user interface zelf zijn 20 negens:
99999999999999999999
Het getal 10788942212008112505 heeft 20 cijfers, en is groter dan de maximale waarde met 19 cijfers van een Int64 (9223372036854775807).
Binnen de REST API’s hanteert Exact Online een tekst in plaats van een Int64 zoals bij XML. Een tekst is ook beter vanwege de mogelijke voorloopnullen.
