størrelse på database

Gamle regnskabsår kan sagtens slettes - der findes en funktion til det samme. Herefter skal databasen eksporteres/importeres. Først reindexeres (gøres natten over), herefter testes tidsforbruges ved eksport/import på en backup (og I kan se om I opnår den nødvendige reduktion af databasen).
C5 kan fungere op til 4 GB, men den er ikke hurtigt.
3 dage er vel ikke helt ved siden af, men få det gjort i en week-end. Det er dyrere men så skal I ikke ligge stille.
En tredie mulighed er at tage en komplet backup, og så nulstille regnskabet ved regnskabsårets start (eller evt et ekstra år). Der er krav om at der skal gemmes 5 år tilbage, men ikke krav om formen. En backup, der kan indlæses, vil opfylde kravene.

Det er korrekt at man anbefaler at gå over på SQL når databasen kommer over 2Gb. Der er altid løsningen at køre med split filer, dog er den ikke anbefattelses værdig.
Men ja hvis i sletter alt data der er mere end 5 år gammel, også køre den kørsel I har som heder reducer databasestørrels, så har I en rum plads igen, men er det ikke som at tisse i bukserne en vinter dag for at holde varmen?
Vedr. SQL og tre dage, så lyder det ikke helt ukorrekt, men det er jo kun den sidste øvelse der vil kræve at I ikke er i systemet, ca en halv dag, så hvis I vil betale for det vil jeres konsulenthus sikkert godt gøre det en aften, mod en merbetaling.
Og ja du kan få lavet en kørsel der sletter de ting du kan undvære som er mere end 5 år gammelt. Men du kan hurtigt køre nedlæg ordre, ordrearkiv ol.

En mulighed er vel også at få installeret og konfigureret SQL serveren, så der kun mangler den sidste del import af data ? Så ville jeg mene at en nedetid på max ½ dag skulle kunne gøre det, men ja, få det gjort enten en weekend eller på tidspunkter hvor I alligevel ligger stille, det koster lidt mere, men gad vide om det ikke er dyrere at ligge stille !

Vi løb ind i samme problem med vores native-db (ca. 2.5 Gb). SQL'en performer (hos os) væsentlig bedre.
Det med de 3 dage lyder lige i overkanten. I teorien kan den sættes til at exportere ved lukketid, og SQL'en kan sættes til at importerer næste morgen. På den måde vil systemet kun være nede 1/2 - 1/1 dag.
Men du skriver I ikke kan exportere data - så har i et seriøst problem, hvis i skal konvertere til SQL.

Per :o)

Når man er langsom ved tasterne er der heldigvis andre der er hurtige. Opfat mit svar som en kommentar.
Jeg vil stadig mene, at 3 dage er lige i overkanten (hvis alt kører efter planen).
Hvis jeg skal bruge store tal:
1. dag) Installation af server- og SQL-software
2. dag) Export/Import af data. (man behøver jo ikke at side og kigge på skærmen imens)
Per :o)

Ting kører aldrig efter planen. Og alene at få det eksporteret og importeret - selv om man ikke behøver kigge på skærmen, så kan man jo sagtens ende i at der er fejl, der skal rettes før det overhovedet kan lade sig gøre. Og rettelser tager tid.
Jeg ville være mere bekymret over at det ikke  var muligt at eksportere data overhovedet - det lyder ikke betryggende. Jeg ville få styr på det først.

Jeg er heller ikke tryg ved den manglende export.

Det med at slette kartoteket og kun gemme backup efter regnskabsåret er afsluttet, det er ikke en løsning for os, vi bruger kartoteket til at gå tilbage og se historik over kunder, så vi kan se om det samme problem opstår igen. Der er nok ingen ánden vej end SQL. Jeg vil bruge jeres råd og få det gjort en weekend. Tak for den hurtige respons. Michael

Ikke for at prale, men jeg konverterede en 2,5 GB fra native til SQL med samlet en halv times (skriver 30 minutter) nedetid.

Vores 2.5 GB tog omkring 3 timer at exporterer, så jeg er synligt imponeret.

Kunden kørte videre på "den gamle" imens der blev konverteret. Senere blev differencen så merget ind i den konverterede. Kunden var kun nede i det tidsrum det tog at lave en filkopi af native versionen.

3 timer? Det tog 3 kvarter at eksportere de 2,5 GB (RAID er godt :-)). Læg nativedatabasen på det ene disksæt og eksporter til det andet. Og man har jo altid minimum to disksæt til rådighed når man vil køre SQL Server.

Hvor mange brugere og hvor mange års data har i  2,0 GB database for en håndværker virksomhed lyder af alt for mange data.

Det lyder som om at i bør have besøg af en "C5 prof" før i gør alt mulig andet.
C5 kan sagtens køre på store databaser men det er dyrt og meget tungt hvis i skal reindexere eller lignende.

I kan sagtens spare på databasen og stadigvæk overholde lovgivning om opbevaring i et læsbart medie i 5 år.

Det skal siges at der selvfølgelig kan være store fordele ved at lægge databasen på en SQL.

3 dage for opsætningen af en SQL lyder rimeligt, det kan gøres kortere men som leverandør skal man gardere sig for uforudsete ting, samtidig er der mange der dropper sikkerheden, vedligeholdelsen og backupen ved en sådan installation.
Det virker som om at dine SQL folk ikke har kendskab til C5, hvis din database er så stor vil jeg ikke føler mig tryg ved at de roder med databasen.

Håber dette kan være en hjælp.
Du er velkommen, hvis du vil vide mere!

Hilsen
Frank

Vi har som du også siger mange data. vi er en sammensat virksomhed med alle faggrupper (el-vvs-maler-murer-tømrer-snedker-gartner-kloak mm., vi er 10 brugere på C5. Vi betjener bla. en boligforening hvorfor vi har brug for at kunne gå tilbage på lejemålet og se hvilke reperationer der er blevet udført tidligere. 5 år tilbage. Vi modtager ordrer elektronisk og direkte ind i C5. Regninger til boligforeningen sendes ligeledes elektronisk og konverteres hos dem om så det passer i deres økonomisystem. De andre kunder får stadig deres regninger via post. Grunden til at vores database er så stor, er ifølge vores eksterne certificerede C5 it tekniker b.la. at vi skriver en uddybende fejlbeskrivelse, ved hver udført ordre. Vi har overvejet at få besøg af et andet It firma, også fordi, som jeg skrev tidligere at dem vi bruger nu ikke kunne få den eksisterende database eksporteret. De havde i fredags sagt at de låste C5 så vi ikke kunne få adgang mandag morgen, hvor de så ville gøre det færdigt. Mandag morgen kunne alle brugere logge på men de blev logget på som supervisor med fuld adgang til hele systemet. It firmaet har vi ikke set noget til i dag. Grunden til at vi valgte dem i første omgang er at de er certificerede og det største firma i vores lokalområde.

Michael

Hej Michael

Jeg tror der er en fejl i databasen, men selvfølgelig ikke lægge hovedet på blokken.
Hvor i landet bor i?
Hvil du være interesseret i at jeg kiggede på den?

Hej Frank

Jeg har også selv leget lidt med tanken om en korrupt database.
vi har nu besluttet at skifte til SQL da vi fandt ud af hvordan licenserne hæger sammen, viser det sig at det ligefrem er ved at kunne hænge sammen. Fordi vi snart skulle til at betale for mere database plads. Vi har bedt to forskellige firmaer om tilbud på at sætte SQL op og overføre data. Så vidt jeg kunne forstå på det ene firma, ville de fange evt. fejl i databasen samtidig. Vi hører hjemme på i det sønderjydske. Tak for tilbudde, men vores sikkerhedspolitik tillader desværre ikke at jeg lader andre få adgang til systemet.

Problemet med fejl skal løses inden overførsel til SQL, modsat ved i ikke om data er OK i SQL, SQL er "kun" en database den løser ikke gamle fejl i databasen, men til gengæld for du en stabil og hurtig database.
Du skal købe database til C5 selvom du har SQL du kan risikere at den faktisk bliver større på en SQL.

Du kan også risikere at den bliver en del mindre. Det kommer meget an på hvordan fordelingen af posterne er. Man kan heldigvis regne ud nøjagtig hvor meget man skal betale for inden man konverterer.

Hvis man skifter til SQL skal man da ikke betale for C5 Native plads eller er det mig der har noget galt i halsen ?

Nu må du ikke kløjes, men du skal stadig betale for database ligesom på native.

Som jeg læser kommentaren fra Egeberg skal jeg stadig købe Native plads, men det er plads til SQL serveren jeg skal købe i stedet for eller hvordan ?

Du skal købe databaselicens som du plejer. Det er ligemeget om det er native eller SQL. Da den ikke har direkte adgang til databasefilerne på SQL, har den en anden måde at regne regnskabets størrelse ud