Illegale RecIDs i KrePost, DebPost, FinPost

Inden du gør noget som helst, så laver du en backup. Dernæst sikrer du at dine primosaldi for indeværende regnskabsår er korrekte - lav en fil med dem, da du kan få brug for dem senere.
Udskriv datastatus.
Dernæst kan du forsøge med check-fix nogle gange - den skal køre fejlfrit igennem to gange - og så efterberegner du. Udskriv en ny datastatus og find forskellene. Disse kartoteker checkes først, og desuden skal alle saldi checkes. Også afstemning med finans for debitor, kreditor og projekt gennemføres. Har du løn, så skal den også stemme.
"Fejlene rettes", men hvordan afhænger af hvilke fejl du har. Nogle gange er det smarteste at starte et nyt regnskab (her kommer filen med primoposter ind), og så løfte data over via finkladde, så indeværende finansår stemmer, og så lade de(t) gamle år være i dmo-regnskabet for opslag. Husk ekstra backup, hvis du laver det stunt.

Tak for svaret - men hvad med konsekvensen ved IKKE at fjerne de illegale recids?

RecId bruges til at styre med, og i nogle tilfælde er det eneste index. Så et ødelagt RecId det forkerte sted kan medføre at hele kartoteket er dødt, men jeg har ikke talt op hvilke kartoteker, der kun har RecId som nøgle.
Og der kan naturligvis ikke laves Notat på de(t) kartotek, hvor de ødelagte RecId er.

Hvor omfattende er skaden?

Undskyld ... Men jeres konversation giver mig associationer i retning af "to børn der leger med en pakke tændstikker i et krutlager".

Jeg har desværre ikke på nuværende tidspunkt overskud til at komme med en formfuldendt og komplet beskrivelse, hvorledes jeg flere gange har haft held til at lappe en sådan ALVORLIG database-fejl. Også i gB-store databaser - uden at skrotte  historikken.

For at redningsaktionen vil skulle kunne lykkes bliver, jeg nødt til at påpege at mariaf's beskrivelse indeholder en enkelt (eller to) væsentlig forglemmelse - foruden og ISÆR en fokusering på, hvad der kan/SKAL gøres for at undgå problemet fremover. Meldingen 'Illigal RecID' er et symptom - Det er vigtigt at gøre noget ved ÅRSAGEN!

Må jeg indtrængende bede om at ixus lige slår på tråden? 6489 3660. Tak.

mariaf og alle andre med interesse for ovenstående er selvfølgelig også meget velkommen.

Holger

Illigal RecID og lign. er et typisk fænomen for C5 Native. Før vi skiftede til SQL, havde vi nedbrud 'mindst' to gange pr. md. Det skulle i følge div. kloge hoveder skyldes, at den Native db ikke kan håndterer databaser > 1 gB. (Vores var over 2).

Per :o)

Skal lige tilføje, at samtlige gange kørte vi check/fix (som mariaf skriver mindst 2 gg) efterfulgt af reindex. (I alt ca. 12 timer)

Per :o(

Selvfølgelig kan det lade sig gøre uden at skrotte historikken - men ikke altid, og du kan ikke vide det før du har været det igennem. Ja, jeg har også haft HELD til det, men ikke hver gang.

Da spørgsmålet ikke gik på at undgå det fremover, gik jeg - måske fejlagtigt - ud fra at er der styr på.

Native kan sagtens håndtere store databaser. Jeg har set db op til 3,5 Gb, der kører uden problemer med RecId. Der er så andre problemer, som gør, at det er en god grund til at skifte til SQL. Min erfaring siger at man bør skifte ved db over 800 Mb, men som sagt er det ikke pga fejl i RecId.

Først - jeg har undersøgt hele systemet nu, og skaden var mindre end hvad jeg 'huskede' i første omgang.

Kartoteker der er 'ok' :

Finans, ordre samt debitor.

Kartoteker der har illegale RecIDs :

KrePost (referencer) : 11738 fejl, hvor langt de fleste er illegale RecIDs

LagPost (GYS!) : Jeg bad den om at udskrive fejlene til en fil, men det stoppede den ved linienummer 1.079.893. Og den er ikke kommet til RecIds endnu. Alle fejl der blev skrevet ud er :

    Der difference på det udlignede antal
    mellem "LagPost" og "Lagerudligninger"

    Der difference på det udlignede beløb
    mellem "Lagerposteringer" og "Lagerudligninger"

Jeg får helt ondt i maven når jeg ser det - men jeg er ikke uddannet i økonomi overhovedet - så jeg ved ikke hvad det betyder præcist.

Det jeg mangler er måske et argument overfor chefen for at få det her rettet. I mit hoved forstiller jeg mig at man kan nustille alle udligninger og så sætte den til at gøre det automatisk, så den saldo(?) udligner. Dvs. manuelle udligninger ryger ud med badevandet.

Alle disse fejl er blevet introduceret en dag hvor systemet sprang i luften, og det er den bagage vi slæber rundt på.

"Sprang i luften"? Hvad dækker det over?
Bruger I valuta, eller har nogen "leget" med kartoteket på et tidspunkt? Og hvilken version kører du på? Hvor stor DB?
Hvordan vedligeholder I normalt? Jeg tænker på reindexering og check af database. Gemmer I jeres backup, så du kan finde en komplet kopi fra før nedbrudet? Ligger de ødelagte RecId efter nedbruddet?
Automatisk udligning er glimrende, når tingene kører, men ikke når der er fejl. Så gør det ofte kun ondt værre.
Mit råd vil være at sige til "chefen" at der er flere fejl i basen end der kan ligge i en fil, og da økonomisystemer jo typisk er hele virksomhedens eksistensgrundlag, så var det nok en god idé at få en prof til at kigge på det. Brug jeres forhandler, hvis han ikke lyder helt underlig over opgaven, ellers find en anden. I skal sikre at konsulenten ved noget om økonomi og ikke bare er prof på Concorden.

'Sprang i luften' dækker over en import/export der gik galt. Alle poster blev fordoblet i C5. Det blev renset ud, hvor resultatet så var at der kom illegale recids. Der er en backup fra før katastrofen - og den indeholder ikke nogen illegale recids. Problemet er at det skete for snart et år siden, så den kan ikke bruges til andet end en advarsel på hvad der kan gå galt ...

Der foregår en reglmæssig vedligeholdelse, hvor reindex indgår, samt check af database.

Vi bruger ikke valuta, version er 1.8 og databasen ligger pt. omkring 1.7 GB. Når vi når ca. 90% sætter jeg en import / export igang (denne gang i et meget meget kontrollerede miljø) - og der bliver taget backup hver dag (på bånd og to maskiner).

I må ikke misforstå mig, jeg anser det som værende et seriøst problem, ud fra en systemadministrators synspunkt, jeg gruer for den dag hvor det hele springer i luften igen, fordi der ikke blev taget hånd om de fejl der er. Men da jeg ved ikke en dyt om regnskab, kan jeg ikke 'se' hvad der kan være af problemer i revisor / regnskabsmæssig forstand, hvis vi lader fejlene være.

Grrrrrrrrrrr. Hvornår lærer "man" at når en eksport/import går galt, så renser man ikke ud, man indlæser backup'en og prøver igen ugen efter.
Nå, problemet for revisor er, at når man skifter til næste regnskabsår, og kører Primo/ultimo, så går det galt. Det kan revisor så bruge meget tid på (som virksomheden naturligvis betaler), og alle bander over det elendige system.
Prøv at tage en kopi, og lav så en gang check/fix og se hvordan det går. Måske er du heldig - det sker jo trods alt :-)
Er du ikke heldig, så skal der en prof på, og det skal gøres INDEN årsafslutningen - eller rettere, inden revisor begynder at korrigere for fejlene.
Det kan i øvrigt ikke svare sig at bøvle med eksport/import i forhold til at købe mere databaseplads - især ikke når det går galt :-)

Er der noget med at min telefon står til udskiftning?

mariaf har så evigt ret. Altid back-up før og efter vigtige ændringer.

Per :o)

Okay, jeg har prøvet en check+ret på lagerdelen :

Før check+ref  :

Lagerudligninger:  366768
Lagerbeholdninger : 26352

Efter check+ref  :

Lagerudligninger:  122690
Lagerbeholdninger : 26304

Efter check+ref  + efter beregn beholdning :

Lagerudligninger:  265240
Lagerbeholdninger : 26304

Der er det samme antal posteringer som før check+ret.

Tja, du mangler da i hvert fald 48 lagerbeholdninger, og næsten 250.000 lagerudligninger, så noget er der da sket.....
Jeg kan ikke råde dig, når jeg ikke selv har fingrene i kagedejen.

Jeg har kommet til at tage et forkert tal til 'før check+ret' :

Lagerudligninger : 268894

Dvs. antallet af 'tabte' lagerudligninger er 3654.

Så ser det jo lige pludselig 'mindre' slemt ud. Men hvis den ikke kan udligne en post, så er det vel fordi der mangler information et andet sted, eller posten 'bare' er defekt - siden den kan genskabe udligningerne ved en lagerregulering?

Find en af dem, og se hvad konsekvens det har på posteringerne. Det vigtige her er jo ikke det edb-tekniske, men at - og hvordan - det har konsekvenser på økonomi.

Jeg husker stadig helt klart, hvordan en virksomhedsejer så ud, en gang hvor vi måtte nedskrive lageret med 4 mio pga edb-fejl.

Fejl i native databasen er oftest pga. af dårligt fungerende/konfigureret netværk.

SQL har mange flere checks, så derfor går den ikke istykker som native gør, og den er nemmere at reparere hvis den gør

Du har ret i at fejlen i Native ofte skyldes dårligt netværk, men der kan faktisk sagtens sættes en parameter på til check - det gør bare Native langsommere, og så forsvinder idéen med at bruge Native frem for SQL.

Jeg fik fjernet dem og satte derefter en lagerregulering. Det betød en 'værdiafgang'(?) på 220 kr. Så det er vidst en 'heldig' fejl.