Har du været ved at skifte en Klassisk Dynamics C5 til SQL-databasen og fået denne mystiske fejl under Multi Import af data?

Så er den gal med dine data.

Der kan være flere forklaringer på HVAD der er gået galt – men fact er at du står tilbage med et eller flere decimaltal, der ligger udenfor det en Microsoft SQL server tillader, men inden for det Klassisk C5 Native databasen accepterer.

 

Klassisk C5 Native databasen kan arbejde med decimaltal (REAL) i intervallet -10^16.384 til 10^16.384 (begge tal eksklusive), men dog kun med en præcision på 16 cifre.

Præcisionen betyder at der kan være 16 betydende cifre. Fx vil tallet 1234567,8910111213 ikke kunne lagres da det har 17 betydende cifre (tal), mens tallet 00001234567,8910111210000 kan lagres da foranstillede og efterstillede nul’er ikke er betydende.

Bemærk: tallene 12345678910111210000000000000 og 123,1234567891011 vil således begge kunne lagres med Native databasen.

 

I C5s Microsoft SQL database lagres decimaltal (REAL) som DECIMAL(28,12) hvilket betyder, at der kan være 28 betydende cifre og de 12 bruges til decimaler.

Bemærk: tallene 12345678910111210000000000000 og 123,1234567891011 (de samme tal som ovenfor) således IKKE kan lagres med Microsoft SQL databasen.

 

Nu er vi jo i yderligheder her, men det kan altså gå galt – fx hvis en kunde har fået scannet et serienummer ind i et beløbsfelt – og på den måde fået lavet meget store tal… Eller der er indsat en del linjer på stort set samme sted på en ordre, indkøb eller et projekt (fordi nye linjenumre mellem to andre linjer beregnes som det kommatal der ligger midt imellem) – og man på den måde har fået lavet rigtigt mange decimaler.

 

Bemærk at decimalerne normalt ikke vil udgøre et større problem da SQL-serveren blot afrunder dem til det korrekte antal decimaler (det kan dog medføre at linjer pludselig sorteres anderledes eller at et unikt index ikke længere er unikt).

De store tal er straks en helt anden sag – og her er ikke en super god løsning.

 

Din importkørsel vil typisk være stoppet et sted når fejlen kommer. Det er guld værd for dig lige at aflure i billedet hvilken tabel den er nået til – fx (her tabellen “ProjTable”):

Eneste løsning er nemlig at du nu går på jagt i filen der indeholder ProjTable (filen er EXPxxxxx.kom hvor xxxxx er tabllens nummer i C5 – i ProjTable’s tilfælde 00129).

Du kan evt. importere filen i Excel og gå på jagt efter et kommatal der er meget stort. Det tal må du så simpelthen rette i dine data – men er det et tal der indgår i en transaktion der skal give 0 – eller der også optræder med hele eller dele af værdien i andre tabeller er opgaven RET diffus.

Alternativt kan du skrive noget kode i Multi Eksport-kørslen der advarer dig om nøjagtigt hvilke poster det går galt i – og så kan du jo kigge på dem manuelt INDEN du forsøger at indlæse dem i C5 for SQL.

Desværre er der mig bekendt ikke andre løsninger – så det er bare at smøge ærmerne op! 🙂