En temmelig overvægtig C5 database kan tage lang tid at beregning – især hvis du kører den på SQL og på en Dynamics C5 før version 2012.
Indtil version 2012 af Dynamics C5 var databaseberegningen forskellig på Native og SQL. Det har den “sjove” sideeffekt at data ikke fylder det samme på Native og SQL, hvilket man kan opleve hvis en kunde skifter fra Native til SQL. Generet er SQL lidt “billigere” i databaseplads (men det kan afhænge af mængden af indexer i de forskellige tabeller).
På Native før C5 version 2012 tager systemet ganske simpelt den fysiske størrelse af C5DATA.xxx-filen. Dvs. inkl. evt. index’er og øvrige ting, samt (hvad værre er) slettede poster. På Native bliver slettede poster liggende i databasen og kan kun genbruges, hvis der siden hen indsættes en post af samme type (fx. kan en slettet ordrelinje erstattes af en ny ordrelinje).
Den eneste måde man kan “frigive” pladsen på i Native er ved at køre en multi-export, oprette en ny database og køre en multi-import af alle data igen. I nogle version af C5 følger der sågar et Databasekomprimerings-værktøj med (et program), der gør netop det. Har man tilretninger der ikke er lavet ordenligt (mht. RecID referencer eller bruger løbenummer-referencer mv.), så er det en RIGTIG dårlig idé – hvad enten værktøjet bruges eller det gøres manuelt… Det vil ganske simpelt ødelægge referencerne i databasen.
På SQL før C5 version 2012 (og efter version 3.0 hvor SQL-kernerne blev indført) skal der periodisk gennemføres en beregning, der tæller antallet af poster i hver enkelt tabel. Dette antal, ganges så med records-størrelsen (dvs. hvor meget postens felter fylder) og derefter ganges der med 1,1 (for at tage højde for at indexer mv. også fylder).
På SQL har det heldigvis altid været sådan at pladsen bliver frigivet – i hvert fald set fra C5s side. På selve SQL-serveren kan man stadig med fordel omorganisere og komprimere databasen for at frigøre plads fra slettede poster – men det er noget SQL-serveren kan gøre for dig.
Da genberegningen på SQL før version 2012 tager noget tid, gemmes resultatet i XALUtil tabellen i krypteret form. Her gemmes det sammen med en dato, så systemet automatisk kan holde øje med at tallet bliver genberegnet hver 90. dag. Systemet advarer (ved login) når det er ved at være på tide at kørslen skal køres, men da den tager noget tid på store databaser, er det bedst at en administrator gør det udenfor arbejdstid.
Ignorerer man advarslerne, vil systemet til sidst antage at databasen er meget stor (64GB), hvorfor systemet vil arbejde ekstremt langsom og advare om at databasen er for stor ift. de indlagte koder.
NB: Vi har fået et par kommentarer om at der findes måder at omgåes databasechecket på. Det er vi skam vidende om. Fælles for de måder vi kender til, er at de (og andre metoder) naturligvis er i klar strid med C5 licensreglerne. Det vil derfor i praksis betyde pirateri – altså at du kører på en ulovlig C5 licens (og er det egentligt ikke lidt dumt at have betalt penge for din licens, hvis du alligevel er pirat?). Microsoft har ansat personale til netop at afsløre den slags pirateri – så vi kan kun kraftigt opfordre til at man holder sig langt væk fra den slags.
Efter version 2012 er databaseberegningen lavet om på såvel Native som på SQL. Det betyder at Native nu følger samme formel som SQL (så data set fra C5 fylder det samme på de to databaser), ligesom databasen automatisk genberegnes når C5 har brug for at vide hvad den er. Til gengæld er beregningen blevet lynhurtig (få sekunder).
Samtidigt har Microsoft sat “en prop” i deres databaseforbrug, så når de udvider databasen ifm. nye frigivelser, så koster det ikke ekstra (dvs. når de nu har udvidet adressefelterne med flere tegn, så koster det ikke kunden noget databasemæssigt).
Vores indtryk er at den nye databaseberegning fungerer rigtigt godt i praksis – dog skal man lige være opmærksom på at C5 kan finde på at blokere for login af nye brugere, såfremt en bruger har en lang kørsel igang der holder TTSer. Læs evt. mere om det her: Langsom login på C5 version 2012 på SQL.