none
RecId - hvad sker der.

    Spørgsmål

  • En af mine kunder har fået problemer med sine notater på ordrelinier efter opdatering fra C5 vers. 4 -> vers. 2012.

    En nyoprettet ordrelinie kan pludselig fange et notat fra en arkiveret ordrelinie som er måske 1 måned gammel eller måske 2 år gammel.

    Jeg begyndte at undersøge RecId, da det jo er dette som binder notater til poster, og fandt til min store overraskelse at de bliver tildelt som vinden blæser. Jeg har lige som en test lavet 5 ordrelinier i den samme ordre og med samme varenummer. Disse liniers recid blev som følger 100031408, 100031648, 100030688, 100030832, 100106192. Rækkefølgen er den rækkefølge de er oprettet i. Hvis jeg ser på de 4 forrige linier (som er oprettet tidligere i dag) er det: 100673136, 99969872, 100030928, 100089808.

    Har nogen iagtaget noget tilsvarende, og hvad har I gjort ved det

    14. november 2012 17:30

Alle besvarelser

  • Hej,

    Hvis transaktionsnummeret er blevet nulstillet (ved en fejl), og der så pludselig opnås adgang til et kartotek (OrdreLinjeArkiv) med 'samme' transaktionsnummer, så har jeg været ude for, at der pludselig udskrives linier / notater fra gamle arkiverede ordre som havde samme transaktionsnummer.

    Hvis det er tilfældet, så sørg for at sætte transaktionsnummeret så højt, at det starter højere end 'slutnummer' i den gamle version.


    M.v.h. René rsl@

    14. november 2012 19:00
  • Hej

    Hvis det er en Native du arbejder på, så er det ikke unormalt.

    På SQL er RecID og RowNumber det samme - nemlig et fortløbende nummer på tværs af alle tabeller... Dermed bliver de tildelt i kronologisk orden og uden huller (men poster kan blive nedlagt igen og dermed kan der opstå huller - disse "genbruges" dog ikke igen).

    På Native er RowNumber et fortløbende nummer indenfor samme tabel (igen - de tildeles kronologisk og uden huller, men poster kan blive nedlagt igen og dermed kan der opstå huller, som ikke genbruges).
    MEN på Native er RecID blot et udtryk for det recordnummer (fysisk byte nummer vil jeg gætte på?) som den pågældende row starter på i den fysiske fil. Dvs. den tildeles ganske simpel ud fra hvor posten gemmes i filen. Dermed vil du også få et nyt nummer ved eksport/import (multi-import tager højde for det - det er den RecID konvtertering den laver til sidst og som er (en af) årsagerne til at man skal huske at sætte referencefelter op / rette ReferenceFields.MAC når man laver egne felter der er recID-pegere.
    På Native kan slettede poster (i samme tabel) i øvrigt genbruges - så derfor kan et recid sagtens blive genbrugt (slettet row bliver erstattet af ny row fra samme tabel).

    HVIS din recid konvertering ved export/import af en eller anden grund er gået galt (så notaternes pegere ikke er blevet flyttet korrekt), eller du på en måde har fået slettet en ordrelinje, uden at slette de tilhørende notater - så vil de jo "dukke op igen" når der bliver oprettet en ordrelinje med samme recID.

    Ifm. fakturering kopieres ordrelinjer fra ordlinie til ordliniearkiv / salesline til saleslinearch - og deres notater kopieres med. Er ordlinjen fuldt leveret (og skal slettes efter fakturakørslen) - eller man selv sletter den efterfølgende, så sørger en tabeltrigger for at det tilhørende notat slettes.

    Mit postulat er at den funktionalitet ikke har virket hos dig - dvs. de tilhørende notater er aldrig blevet slettet (men er dog blevet kopieret til nye notater der peger på ordlinjearkiv/saleslinearch). Dermed ligger de notater i databasen uden at have en linje at høre til - indtil du opretter en ny ordrelinje, der tilfældigvis får tilknyttet det recid den gamle linje havde.

    Det er nok værd at undersøge om notaterne i din nye installation slettes korrekt (eller der er en tilpasning der forhindrer det). Men ellers bør du jo nok lave en kørsel der drøner alle notater igennem med fileid = ordlinie/salesline og hvor recid ikke findes. Dem kan du så slette... Dermed forhindrer du at gammel skade dukker op på den måde du oplever.


    MVH gsl@systemconnect.dk Se også: http://blog.systemconnect.dk/

    • Foreslået som svar af Gert Lynge 15. november 2012 07:42
    15. november 2012 07:40
  • Hej Gert

    Det er en native, og jeg regnede også med at det var et fortløbende nummer indenfor tabellen, men som du ser af det oprindelige spørgsmål bliver de tildelt tilfældigt indenfor et interval på ca. 20.000 numre - både stigende og faldende.

    Da jeg lavede de 4 testlinier, var der ikke andre på systemet, og dermed blev det overhovedet ikke oprettet noget ind imellem.

    m.v.h

    Kurt

    15. november 2012 08:23
  • Hej René

    Det er ikke transaktionsnummeret der er problemer med - det er RecId, som er en nummerserie man mig bekendt ikke kan pille ved.

    mvh

    Kurt

    15. november 2012 08:25
  • Hej Kurt

    Jeg har ikke udtrykt mig klart nok. Det er IKKE en fejl at dine recids bliver tildelt på den måde. RowNumber/løbenummer er fortløbende indenfor tabellen på Native. RecID er ikke.

    De 4 testlinjer du opretter går ind og lægger sig på gamle slettede poster i samme tabel (det gør native databasen - den genbruger plads, men kun til poster fra samme tabel). Og dermed får de samme fysiske RecID som de gamle slettede linjer (fordi RecID i native blot er en simpel filposition - altså afhængig af fysisk placeringen af posten i filen).

    Ligger der så notater der pegede på de gamle linjer, så kommer de til at ligge under de nye linjer.

    Fejlen er ikke tildelingen af recid - det er at du har gamle løse notater i filen (der peger på ikke eksisterende ordrelinjer). Det er noget jeg har været med til at rydde op i flere gange.

    De notater er jo kopieret så de ligger en gang mere i notattabellen og peger på den tilsvarende arkivlinje. Ellers ville de jo ikke komme med ud på den faktura der blev lavet dengang.

    Så fixet er ganske simpelt at slette dem (det forsvinder kopien der nu peger på arkivlinjen jo ikke af). Men prøv det i et testsystem hvis du ikke tror mig :-).

    Inden oprydningen bør du dog som sagt lige sikre dig at notaterne nu bliver slettet korrekt... For du kan jo stadig have en tilpasning i applikationen der på en eller anden måde forhindrer det...


    MVH gsl@systemconnect.dk Se også: http://blog.systemconnect.dk/

    • Foreslået som svar af Gert Lynge 15. november 2012 08:33
    15. november 2012 08:33