![\"SQL](\"http:\/\/blog.systemconnect.dk\/wp-content\/uploads\/2015\/07\/Numeric-value-out-of-range.jpg\")
<\/a>SQL fejl<\/b>
SQL databasen har signaleret f\u00f8lgende fejl:
[Microsoft][ODBC SQL Server Driver]Numeric value out of range
\u00d8nsker du at gentage transaktionen?<\/p><\/div>S\u00e5 er den gal med dine data.<\/p>\n
Der kan v\u00e6re flere forklaringer p\u00e5 HVAD der er g\u00e5et galt – men fact er at du st\u00e5r tilbage med et eller flere\u00a0decimaltal, der ligger udenfor det en Microsoft SQL server tillader, men inden for det Klassisk C5 Native databasen accepterer.<\/p>\n
<\/p>\n
Klassisk C5 Native databasen kan arbejde med\u00a0decimaltal (REAL) i intervallet -1016.384<\/sup> til 1016.384<\/sup> (begge tal eksklusive), men dog\u00a0kun med en pr\u00e6cision p\u00e5 16 cifre.<\/p>\n Pr\u00e6cisionen\u00a0betyder at der kan v\u00e6re 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.<\/p>\n Bem\u00e6rk: tallene 12345678910111210000000000000 og\u00a0123,1234567891011 vil s\u00e5ledes\u00a0begge kunne lagres med Native databasen.<\/p>\n <\/p>\n I C5s Microsoft SQL database\u00a0lagres decimaltal (REAL) som DECIMAL(28,12) hvilket betyder, at der kan v\u00e6re 28 betydende cifre og de 12 bruges til decimaler.<\/p>\n Bem\u00e6rk: tallene 12345678910111210000000000000 og\u00a0123,1234567891011 (de samme tal som ovenfor) s\u00e5ledes\u00a0IKKE kan lagres med\u00a0Microsoft SQL databasen.<\/p>\n <\/p>\n Nu er vi jo i yderligheder her, men det kan alts\u00e5 g\u00e5 galt – fx hvis en kunde har f\u00e5et scannet et serienummer ind i et bel\u00f8bsfelt – og p\u00e5 den m\u00e5de f\u00e5et lavet meget store tal… Eller der er indsat en del linjer p\u00e5 stort set samme sted p\u00e5 en ordre, indk\u00f8b eller et projekt (fordi nye linjenumre mellem\u00a0to andre linjer\u00a0beregnes som det kommatal der ligger midt imellem) – og man p\u00e5 den m\u00e5de har f\u00e5et lavet rigtigt mange decimaler.<\/p>\n <\/p>\n Bem\u00e6rk at decimalerne normalt ikke vil udg\u00f8re et st\u00f8rre problem da SQL-serveren blot afrunder dem til det korrekte antal decimaler (det kan dog medf\u00f8re at linjer pludselig sorteres anderledes eller at et unikt index ikke l\u00e6ngere er unikt).<\/p>\n De store tal er straks en helt anden sag – og her er ikke en super god l\u00f8sning.<\/p>\n <\/p>\n Din importk\u00f8rsel vil typisk v\u00e6re stoppet et sted n\u00e5r fejlen kommer. Det er guld v\u00e6rd for dig lige at aflure i billedet hvilken tabel den er n\u00e5et til – fx (her tabellen “ProjTable”):<\/p>\n Eneste l\u00f8sning er nemlig at du nu g\u00e5r p\u00e5 jagt i filen der indeholder ProjTable (filen er EXPxxxxx.kom hvor xxxxx er tabllens nummer i C5 – i ProjTable’s tilf\u00e6lde 00129).<\/p>\n Du kan evt. importere filen i Excel og g\u00e5 p\u00e5 jagt efter et kommatal der er meget stort. Det tal m\u00e5 du s\u00e5 simpelthen rette i dine data – men er det et tal der indg\u00e5r i en transaktion der skal give 0 – eller der ogs\u00e5 optr\u00e6der med hele eller dele af v\u00e6rdien i andre tabeller er opgaven RET diffus.<\/p>\n Alternativt kan du skrive noget kode i Multi Eksport-k\u00f8rslen der advarer dig om n\u00f8jagtigt hvilke poster det g\u00e5r galt i – og s\u00e5 kan du jo kigge p\u00e5 dem manuelt INDEN du fors\u00f8ger at indl\u00e6se dem i C5 for SQL.<\/p>\n Desv\u00e6rre er der mig bekendt ikke andre l\u00f8sninger – s\u00e5 det er bare at sm\u00f8ge \u00e6rmerne op! \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":" Har du v\u00e6ret ved at skifte en Klassisk Dynamics C5 til SQL-databasen og f\u00e5et denne mystiske fejl under Multi Import af data? S\u00e5 er den gal med dine data. Der kan v\u00e6re flere forklaringer p\u00e5 HVAD der er g\u00e5et galt … L\u00e6s resten <\/a><\/p>\n