Sleutelwijziging ENCDEN > ENCHER, ENCDEN staat toch nog in betalingsrun?

[pascal]

4-10-2009 is sleutel LORE_RID, ENCDEN veranderd in ENCHER

Kijk ik nu onder 7-4-5-1, laatste betalingsrun van 8-10-2009
F2, 1, F2 Raadplegen Binnenlandopdrachten
dan staat ENCDEN er toch nog tussen
Ik heb geen fout vwb ENCDEN kunnen vinden in het logboek sleutelwijzigingen

[Wouter Rijnbende]

Tsja... het logboek bekijken stond niet in de handleiding  (waarmee ik niet zeg dat dat niet nuttig is).

Hoe dan ook, zie http://ha1.heartprofit.nl/profit/index.php?topic=21336.msg31585#msg31585, dan was je e.e.a. écht wel tegen gekomen.

In principe kunnen wij deze wel met de hand aanpassen, maar hoeveel heb je er nog meer?

Je niet aan de regels houden kán impliceren dat wij uren of dagen bezig zijn met herstel, waarvan je niet mag verwachten dat wij dat gaan betalen.

Inventariseer eerst eens even wat je nog meer omgenummerd hebt en niet gekontroleerd hebt, en waar de oude sleutelwaarde nog in voorkomt, dan kunnen we daarna in een keer je lijstje wegwerken.

[pascal]

Hm, die TS tool is toch wat lastig imo, moet ik even tijd in steken.
Kom er binnenkort op terug.

[pascal]

Ik ben nog wel even bezig met het controleren van de rest, maar heb voor ENCDEN gevonden dat deze in ADBF.DBF en ADWR.DBF nog niet gewijzigd is.

Willen jullie dit aub al (obv nacalculatie) aanpassen, zodat ik de rest kan inventariseren?

Ik heb trouwens een aangepaste versie van TS.EXE gebruikt die ik iets vriendelijker vond werken. Is dit ok?
http://www.xs4all.nl/~gverkade/ts/

[Wouter Rijnbende]

ENCDEN gewijzigd in ENCHER in ADBF en ADWR (alleen Produktiebestanden).

[Wouter Rijnbende]

Er is hier intern verwarring ontstaan over het feit dat jij mogelijk nog gewoon aan het testen was in de testbestanden.

Klopt dat? Was je nog aan het testen in test, en kun je niet verder zolang ik die Relatie niet omgenummerd hebt in die 2 bestanden, óf had je de boel al in produktie omgenummerd, en kwam je er toén pas achter dat ENCDEN niet was omgenummerd.

Ik heb i.i.g. het laatste begrepen uit je post.

[pascal]

Ik heb het in Test uitgevoerd, maar daarna ook in Produktie. Pas toen het in produktie al omgenummerd was, kwam ik erachter dat een deel van de ENCDEN-id's niet omgenummerd is.
Dit komt doordat ik de text-search niet heb uitgevoerd om te controleren of de identiteit nog voorkomt. Ik ging er vanuit dat de log-file ook al enige zekerheid gaf over het slagen van het omnummeren (ten onrechte zoals nu blijkt).

Ik zal de rest v/d identiteiten ook nog doorzoeken, maar dit zal ik wat later rapporteren (zijn er nog +/- 120 stuks).

[Wouter Rijnbende]

Dan had ik je goed begrepen 

[pascal]

Mmm... Ik heb nogmaals een zoekactie gedaan naar ENCDEN middels TS.
Nu vind ik nog meer databases, maar dit is mbv TS erg lastig te rapporteren. Ook omdat er geen logfile gecreeerd kan worden, met een overzicht van de gewijzigde DBF-bestanden (deze moet je met de hand noteren).

Nu heb ik de stoute schoenen aangetrokken en mbv een andere tool (Agent Ransack) een zoekactie uitgevoerd. Dit levert de volgende databases op die ENCDEN bevatten, zie schermafdrukken.

[Wouter Rijnbende]

Ik heb nog een regeltje toegevoegd aan het lijstje:

Je moet voordat je de TekstSearch uitvoert eerst nog even alle bestanden reorganiseren.
Mag in principe ook vóór het uitvoeren van de Sleutelwijzigingen.

Doe je dat niet, dan kán het zo zijn dat de oude waarde nog wordt gevonden in gedelete records.
Daar weet de Tekst Search nl. niets van af.

Tsja... en verder... werkt die Tekst Search methode wat mij betreft ook niet (afdoende), immers:

a. een Tekst Search weet niets af van Bedrijfs-Identifikaties. Je hoeft dus nog maar ergens een ander bedrijf te hebben waarin ook een Relatie ENCDEN voorkomt, en de Tekst Search zal het voorkomen vinden.

b. een Tekst Search weet ook niets af van velden. Stel dus dat je een Ingekomen Faktuur boekt op ENCDEN, en in de Omschrijving wordt "ENCDEN / 16001" gegenereerd (Crediteur + Faktuurnummer), dan zal Profit-Change-Key niet in de omschrijving omnummeren, terwijl de Tekst Search dit voorkomen wel vindt.

Kortom, als de Tekst Search iets vindt, zegt dat nog niet bijzonder veel. Hooguit geeft het jou misschien wel een indikatie in welke systeemdelen je extra goed moet kontroleren of je sleutels inderdaad wel zijn omgenummerd.

Nb: In jouw geval kan het in theorie overigens ook nog aan jouw Tekst-Search variant liggen.

[pascal]

Ok. Wat kan ik nu als beste doen?
Alle bestanden reorganiseren en vervolgens nogmaals een tekstsearch doen?

Ik zie ENCDEN in het systeem zelf onder 7-4-2-2 Raadplegen ingekomen fakturen (maar er staan ook nog oude ENCDEN-fakturen in die niet geconverteerd zijn).
Onder de eerder gemelde 7-4-5-1, laatste betalingsrun van 8-10-2009 F2, 1, F2 Raadplegen Binnenlandopdrachten staat ENCDEN niet meer: deze zijn goed omgezet naar ENCHER.

[Wouter Rijnbende]

Ok. Wat kan ik nu als beste doen?
Alle bestanden reorganiseren en vervolgens nogmaals een tekstsearch doen?

Reorganiseren om uit te sluiten dat de Tekst Search voorkomens vindt in deleted records.

Daarna nogmaals een Tekst Search doen.

Vervolgens vaststellen om welke tabellen (entiteiten) het gaat, en in die systeemdelen kontroleren of je de oude waarde nog tegenkomt.

Dus, ADFI = Ingekomen Fakturen, en vervolgens kun je bij Ingekomen Fakturen kijken of er nog Ingekomen Fakturen op Crediteur ENCDEN staan (zul je nu niet meer vinden, want die heb ik daar zojuist gewijzigd in ENCHER).

[Wouter Rijnbende]

Ik ben overigens druk op zoek naar een oorzaak. De overeenkomst tussen de bestanden ADBF en ADFI zijn, dat beide zullen omnummeren volgens een index waarbij de Relatie-id getrimd wordt (spaties a/d rechterkant staan niet in de index), en het eerst volgende veld een Faktuurnummer is.

Kombineer dit met de toevallige situatie dat jij én een ENCDEN gedefinieerd hebt én een ENCDEN01 (die kwa linkerdeel met ENCDEN bestaat) én het feit dat het eerst volgende indexveld het Faktuurnummer is én jij fakturen hebt die met 01 beginnen, is het voor de index niet duidelijk of een sleutelwaarde

"ENCDEN012345"

staat voor

"ENCDEN" + "012345"

of voor

"ENCDEN01" + "2345"

Op enig moment kan het dus voorkomen dat je in je database een situatie krijgt:

"ENCDEN"+"012345"  -> ENCDEN012345
"ENCDEN01"+"4000"  -> ENCDEN014000
"ENCDEN"+"900000"  -> ENCDEN900000

Nu gaan we ENCDEN omnummeren, konstateren we bij het 2e record dat de Crediteur niet meer gelijk is aan ENCDEN, en stopt de run ermee, waardoor ENCDEN900000 niet wordt omgenummerd.

Om te voorkomen dat dit een volgende keer weer fout gaat, zal ik de indexen van ADFI en ADBF aanpassen.

[pascal]

Erg bedankt Wouter, ik zal sowieso vanavond alles reorganiseren, textsearch uitvoeren en de gevonden bestanden controleren.

[Wouter Rijnbende]

Om te voorkomen dat dit een volgende keer weer fout gaat, zal ik de indexen van ADFI en ADBF aanpassen.

Iets wat denk ik nog beter (algemener) is, is kijken of ik de module Profit-Change-Key zodanig kan aanpassen, dat deze niet meer velden omnummert volgens een index waarbij het betreffende veld getrimd is én niet het laatste veld in de index is. Het zal er dan hooguit op neer komen dat bepaalde tabellen langer zullen duren, omdat ze ineens sequentieel moeten worden doorlopen, maar dan wel 'goed' gaan.  De tabellen die dan 'lang' duren zullen eerder te vinden zijn zijn al dit soort uitzoekwerk wat we nu hebben waar het mogelijk verkeerd is gegaan...