Sleutelwijziging, TERZAL > WIEZAL, C-TERZAL + D-TERZAL nog aanwezig?

[pascal]

In de test-omgeving heb ik de sleutelwijziging LORE_RID TERZAL > LORE_RID WIEZAL uitgevoerd.
Bij controle kom ik echter in de databases ADBB.DBF, ADBO.DBF en ADOB.DBF de waardes C-TERZAL en D-TERZAL nog tegen:

\FOX\AD\ADTF\ADBB.DBF rubriek REKIN waarde D-TERZAL
\FOX\AD\ADTF\ADBO.DBF rubriek ADBO_NRA waarde C-TERZAL
\FOX\AD\ADTF\ADOB.DBF rubriek REKIN waardes C-TERZAL en D-TERZAL

Via welk menu zou ik ze tegen moeten komen?

Wanneer ik op zoek ga in de test-omgeving vind ik de waarde C-TERZAL danwel D-TERZAL nergens terug.
Maak ik een query dan vind ik in rubriek REKIN danwel ADBO_RNA de waardes wel terug, zie schermafdruk.

LET WEL: ik heb (vanwege deze bevindingen) de backup van produktie- en testomgeving teruggezet, in de test zijn de resultaten dus niet meer te vinden.
Ze staan wel in een kopie-database op de server, deze kan ik vanaf mijn pc wel benaderen (G en I koppelen met lokatie kopie oude databases) maar via een Remote desktop-sessie op de terminal server niet (koppeling G- en I-schijf zijn voor alle gebruikers die inloggen gelijk).

[Wouter Rijnbende]

De een kan geen kwaad, de ander wel...

De records die je ziet, waarbij het bedrijfs-id in kleine letters is opgenomen, betreffen verwijderde boekingsrecords, die we nog even niet echt verwijderd hebben, maar onder een kleine bedrijfs-id nog even bewaren. Deze worden niet omgenummerd (en hoeft op zich ook niet).

Maar, in een van de 2 schermen heb je ook TERZAL met de bedrijfs-id in hoofdletters ! en dat zou wel fout zijn.
Of is dat soms nádat je de tabel weer had teruggehaald ?

[Wouter Rijnbende]

NB: Verder heb je héél goed opgelet met het achteraf kontroleren ! 

[pascal]

De query is op de tabel met datum 6-3-2011. In dezelfde database is bij crediteuren LORC.DBF TERZAL ook omgezet in WIEZAL, zie schermafdruk.

NB: Verder heb je héél goed opgelet met het achteraf kontroleren ! 

Door schade en schande word je wijzer

[Wouter Rijnbende]

Tsja... de velden ADBO_RNV en ADBO_RNA zou hij verder gewoon moeten verwerken.
Het zou kunnen zijn dat ADBO eerst gereorganiseerd zou moeten worden.

Dus, als je de testomgeving hebt teruggezet (waarom zet je trouwens ook produktie terug als je alleen maar in test aan het testen bent?) zou ik zeggen "reorganiseer die ADBO eerst eens, en probeer het dan nog een keer".

[pascal]

Ok, dit zal ik testen.

Ik zet ook produktie terug omdat ik bang ben dat er iets in gedeelde (systeem) bestanden zou kunnen wijzigen, ondanks dat ik ook wel kan nagaan dat er in SY-bestanden geen rubriek LORE_RID voorkomt gevuld met de waarde TERZAL.
Het is meer een kwestie het zekere voor het onzekere nemen.

[pascal]

Ik heb inmiddels nogmaals rubriek LORE_RID, waarde TERZAL omgezet naar WIEZAL. Nu in de Test en de resultaten laten staan, zodat jullie ook kunnen zien wat er mis is.
Produktie-bestanden zijn naar Test-omgeving gekopieerd, alle bestanden gereorganiseerd, TERZAL > WIEZAL uitgevoerd, daarna nogmaals alle bestanden gereorganiseerd (dus incl ADBO) en codepages aangebracht.

Text-search op de testbestanden levert nog steeds waardes TERZAL op. Heel vaak betreft het een tekstregel, maar in onderstaande gevallen is dit niet het geval:

G:\FOX\AD\ADTF\ADAP.DBF veld ADAP_GNR, waarde TERZAL
.. \AD\ADTF\ADBB.DBF veld REKIN, waarde D-TERZAL
.. \AD\ADTF\ADOB.DBF veld REKIN, waarde C-TERZAL en D-TERZAL
.. \AD\ADTF\ADBO.DBF veld ADBO_NRA waarde TERZAL
.. \LO\LOTF\LOVR.DBF veld PRKRIT waarde TERZAL

Ik hoop dat jullie hier eens naar kunnen kijken?

[Wouter Rijnbende]

G:\FOX\AD\ADTF\ADAP.DBF veld ADAP_GNR, waarde TERZAL

Yep. Deze is fout. Nu moeten we nog even uit zien te vinden waarom deze niet omgenummerd is.

.. \AD\ADTF\ADBB.DBF veld REKIN, waarde D-TERZAL

Aangetroffen, doch in 'Verwijderde Boekingen', die niet echt verwijderd zijn, maar waarvan de Bedrijfs-Identifikatie in de tabel gewijzigd is.
Deze kan geen kwaad, maar ja, hoe herken jij dat met je Search?
Ervanuitgaande dat jij ook veld REKIN weet te vermelden, kun jij dan ook konstateren dat veld XXSU_SID niet overeenkomt met je Bedrijfs-id?

.. \AD\ADTF\ADOB.DBF veld REKIN, waarde C-TERZAL en D-TERZAL

Deze is niet omgenummerd. Ook fout gegaan dus.

.. \AD\ADTF\ADBO.DBF veld ADBO_NRA waarde TERZAL

Ook fout.

.. \LO\LOTF\LOVR.DBF veld PRKRIT waarde TERZAL

Ja, en deze wordt heel lastig, immers, er hier is een Relatie-Id ingevuld in een veld "Produktiekriterium", terwijl een "Produktiekriterium" van zichzelf niet weet dat ze als Relatie-Id gebruikt kan worden. Waar gebruiken jullie dit Produktiekriterium voor? Ik bedoel, waarom vul je daar een Relatie-Id in ?


V.w.b. de foutieve zal ik eens kijken of ik kan vinden waarom dit foutgelopen is...
Overeenkomst van degene die foutgelopen zijn is i.i.g. dat het allen situaties betreft waarin de Relatie niet voorkwam als veldwaarde "TERZAL" maar als "C-TERZAL".

[Wouter Rijnbende]

Hmmm.... Als je alleen al even naar de Sleutelwijzigingslogfile kijkt m.b.t. ADBO, dan zie je dat er wel degelijk zo'n 6800 items alleen al in ADBO_RNV zijn omgenummerd. Toch zijn er zo'n 200 records die niet zijn omgenummerd... 

[pascal]

.. \AD\ADTF\ADBB.DBF veld REKIN, waarde D-TERZAL

Aangetroffen, doch in 'Verwijderde Boekingen', die niet echt verwijderd zijn, maar waarvan de Bedrijfs-Identifikatie in de tabel gewijzigd is.
Deze kan geen kwaad, maar ja, hoe herken jij dat met je Search?
Ervanuitgaande dat jij ook veld REKIN weet te vermelden, kun jij dan ook konstateren dat veld XXSU_SID niet overeenkomt met je Bedrijfs-id?

Er is in ADBB.DBF maar 1 waarde van D-TERZAL aanwezig; veld XXSU_SID heeft hier een waarde 'bbb-beton', dus met kleine letters (maar dat hebben ze volgens mij allemaal).

[Wouter Rijnbende]

veld XXSU_SID heeft hier een waarde 'bbb-beton', dus met kleine letters (maar dat hebben ze volgens mij allemaal).

Nope. De bedrijfs-Id zal normaliter in hoofdletters staan; dat ze hier in kleine letters staat komt door het mechanisme waarbij de boeking weliswaar verwijderd wordt, maar we die toch nog even in de database willen bewaren. Hoe dan ook, jij kunt dus op veldnaamniveau zoeken (mooi  ), en moet even weten dat als de Bedrijfs-Identifikatie (XXSU_SID, LOSU_SID, LOBE_BID) veld niet gelijk is aan het Bedrijfs-Id waarin je omnummert, het loos alarm zal/kan zijn.

"Kan zijn" omdat met dat ik dit schrijf, ik me ook alweer bedenk dat er inrichtingssituaties zijn waarbij je in Bedrijf A en Bedrijf B precies dezelfde Relatie-Id's hebt (worden 1:1 onder water doorgekopieerd), waar A orders kan uitbesteden aan B, en om die reden die relaties ook 1:1 moeten lopen, en je vervolgens in bedrijf A een relatie TERZAL gaat omnummeren, maar je het in B nog niet gedaan hebt (wat wel zal moeten wil het 1:1 blijven lopen). Dus, een waarde vinden in een ander bedrijf moet iets genuanceerder, immers, als je het in een ander bedrijf vindt (in hoofdletters) dan moet een belletje gaan rinkelen of de sleutelwijziging niet ook in dát bedrijf moet worden opgestart.

Voor jullie nu: als je het vindt bij een bedrijfs-id in kleine letters, dan kun je e.e.a. negeren.

[Wouter Rijnbende]

Hmmm.... Als je alleen al even naar de Sleutelwijzigingslogfile kijkt m.b.t. ADBO, dan zie je dat er wel degelijk zo'n 6800 items alleen al in ADBO_RNV zijn omgenummerd. Toch zijn er zo'n 200 records die niet zijn omgenummerd... 

Mooi... hiervan is de oorzaak gevonden...

Het probleem wordt veroorzaakt door iets wat in 2000 en 2001 is foutgegaan.

Een Relatie heeft één Debiteuren-/Crediteuren Verzamelrekening. Zodra je de Verzamelrekening van de Debiteur-/Crediteur wijzigt, wordt het saldo overgeboekt van de oude Verzamelrekening naar de nieuwe, zodat er nog steeds maar boekingen zijn voor één Verzamelrekening (degene die bij de Debiteur-/Crediteur staat). Bij dat overboeken van dat saldo zal het mis moeten zijn gegaan, want in ADBO staan nog boekingen van TERZAL v.w.b. Verzamelrekening Z13000 i.p.v. de huidige 13020.
En alleen de boekingen van 13020 worden omgenummerd; daar loopt e.e.a. dus op fout !

Omdat ADAP de Periodetotalen bevat van de boekingsgegevens uit ADBO, is dit dus ook de oorzaak voor ADAP. Daarin gaat precies hetzelfde fout.

[Wouter Rijnbende]

ADBB is dus verder niet fout. Je krijgt Profit-Change-Key trouwens niet eens opgestart als er nog niet doorgeboekte Batchboekingsregels aanwezig zijn.

ADOB (Oorspronkelijke Batchboekingen) is wel fout, en die wordt zo te zien echt overgeslagen. Op zich staat er in ADOB geen informatie die echt bewaard moet blijven (die tabel kan op ieder moment opgeschoond worden), maar dat neemt niet weg dat er wel in omgenummerd zal moeten worden.

[Wouter Rijnbende]

Profit-Change-Key is nu v.w.b. ADBO en ADAP zodanig aangepast dat deze rekening houdt met een saldo op andere Debiteuren-/Crediteuren Verzamelrekeningen (zo bijv. ook de Distributierekening Debiteuren-/Crediteuren). Daarnaast wordt ADOB nu verwerkt (o.b.v. een nieuwe index).

G:\FOX\AD\ADTF\ADAP.DBF veld ADAP_GNR, waarde TERZAL

Aangepast; staat al op jullie systeem.

.. \AD\ADTF\ADBB.DBF veld REKIN, waarde D-TERZAL

Niets aan gedaan. Bij de gratie dat je toch niet mag omnummeren als er nog Batchboekingen open staan, valt er vanzelf al nooit wat om te nummeren in deze tabel. De melding die je kreeg was ook loos.

.. \AD\ADTF\ADOB.DBF veld REKIN, waarde C-TERZAL en D-TERZAL

Aangepast; staat op jullie systeem.
Let op: In de Produktiebestanden zul je eerst nog tabel ADOB moeten reorganiseren, omdat er een nieuwe index bij is gekomen t.b.v. dit omnummeren.

.. \AD\ADTF\ADBO.DBF veld ADBO_NRA waarde TERZAL

Aangepast; staat op jullie systeem.

.. \LO\LOTF\LOVR.DBF veld PRKRIT waarde TERZAL

Niet aangepast, en kunnen we misschien maar beter niet aan beginnen ook; maar, mogelijk hangend aan je uitspraak waar je dit voor gebruikt.
Ik vermoed dat je (bewust of onbewust) gebruik maakt van dit veld om behoeftes uniek te maken naar een Debiteur-id, en in dat geval kun je misschien beter zelf de openstaande orders van die debiteur even doorlopen en aanpassen, dan dat we hier wat voor gaan maken. We kunnen er natuurlijk best wat voor maken (kost gewoon geld), maar realiseer je wel dat we niet zomaar even een index op zo'n groot bestand erbij gaan maken puur er alleen voor jullie Sleutelwijzigingen. Ofwel, aanpassen impliceert om te beginnen dat de tabel LOVR ineens record voor record doorlopen zal moeten worden, hetgeen de performance niet echt ten goede komt (waarmee e.d. aanpassing dus al minimaal achter een parameter zal moeten komen te hangen (= 4 uur)).


In de Testbestanden heb ik opnieuw de Sleutelwijzigingsopdracht van TERZAL naar WIEZAL uitgevoerd. In de aangepaste bestanden is e.e.a. nu wél omgenummerd (met uitzondering dan van de records waarbij het bedrijfs-id in kleine letters staat).

[pascal]

Wouter, geweldig nieuws!

Ik zal reorganiseer de Produktie-bestanden komend weekend, dus dan komt ADOB automoatisch mee.

De verkooporders waar de waarde TERZAL voor PRKRIT voorkomt bevatten allemaal maar 1 onderliggende regel met vrachtkosten; het blijkt dat dit een uitzondering is (we hebben een paar keer voor een klant als vervoerder gefungeerd). Dit is dus in orde, hoeft geen aanpassing voor gemaakt te worden.