da sv en da hbs_lat en en en ru en en en en en en en da da en da da da en da da en fr nb da en da da da da da en da ceb en da en da pl da da hbs_lat da da ceb en en da pl da da da da da da da da da da da en da ceb en en da pl da da sv en en da ceb en en da pl da sq en da da ceb en en da de da da da da da da da da da da da ceb en en en da ceb ro ceb da ceb da ceb da
Australia (English)Brasil (Português)Česko (Čeština)Deutschland (Deutsch)España (Español)France (Français)Indonesia (Bahasa)Italia (Italiano)Magyarország (Magyar)Nederland (Nederlands)Polska (Polski)România (Română)Singapore (English)Türkiye (Türkçe)United States (English)Poccия (Pycckий)ישראל (עברית)المملكة العربية السعودية (العربية)ไทย (ไทย)대한민국 (한국어)中国 (中文)台灣 (中文)日本 (日本語)香港特別行政區 (中文)
RecId - hvad sker der.
Log på for at bedømme
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 linjer (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
Log på for at bedømme
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 linjer / 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.
14. november 2012 19:00
Log på for at bedømme
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 eksport/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
Log på for at bedømme
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.
15. november 2012 08:23
Log på for at bedømme
Det er ikke transaktionsnummeret der er problemer med - det er RecId, som er en nummerserie man mig bekendt ikke kan pille ved.
15. november 2012 08:25
Log på for at bedømme
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
© 2022 Microsoft Corporation. Alle rettigheder forbeholdes.
Opdater din Microsoft profil