Heart-Profit ERP

Bij het uitvoeren van de sleutelwijziging rubriek LORE_RID, oude waarde WAABAR nieuwe waarde WAAEDE
krijg ik onderstaande fout te zien in de logfile sleutelwijzigingen (plaatje 1).
Ik heb onder menu 2-9-3-1 Raadplegen kontakten gekeken (tabel PKKO?) maar zie hier geen WAABAR staan (plaatje 2).

Uiteraard eerst in de Test-omgeving uitgevoerd, dus geen bloedspoed.

:17c:

Raar... verder geen vreemde dingen gemerkt?

De fout status wordt getoond als het systeem wel aanvangt wijzigingen aan te brengen in een tabel, maar het einde van de tabel niet haalt, bijvoorbeeld omdat het proces voortijdend beëindigd wordt, danwel je eruit knalt. In theorie is nog een mogelijkheid "gevraagde gegevens geallokeerd", gekombineerd met het (onterecht) op Esc kunnen drukken.

Ik heb zojuist WAAEDE weer terug hernoemd naar WAABAR, en nu gaat PKKO feilloos.
Wel 'hangt' nu de boel op ADWR, waarhij hij meer dan 1 miljoen sleutelwijzigingen denkt te moeten aanbrengen.  Ik probeer e.e.a. nu opnieuw, nadat ik ADWR gereorganiseerd heb. Na reorganisatie gaat ook deze goed.

Blijft dus vreemd, want het lijkt er wel op dat hij na PKKO verder gegaan is, immers, bij tabel LORE (Relaties, die hij als laatste doet bij het omnummeren van een Relatie) staat voor deze Relatie wel '1 verwerkt'.

Even goed in de gaten houden.

Hmm... er valt me nog iets op...

Kolom 'Vws' (verwerkingssoort) staat op "I" wat zou moeten betekenen dat deze Sleutelwaarde volgens een Index werd omgenummerd. Er is echter geen Index op Projekt-Id (PKKO_PID), dus de status had maximaal "IS" (Index + Skip) kunnen zijn. Ik duik er nog even in...

Nou... dat heeft er vast wel wat mee te maken...  :smile:

Er is geen index op veld PKKO->PKKO_PID, dus die kan i.d.d. niet via een Index (code I). De tabel zal Sequentieel (S) moeten worden doorlopen (maar doet dat volgens een tabel met een index op bedrijfs-id, opdat niet alle Kontakten van de andere bedrijven doorlopen hoeven te worden).

O.b.v. de verwerkingssoort code, is intern de afhandeling kompleet anders, en 'stopt het systeem na 1 voorkomen', danwel 'zoekt ze net zo lang verder tot de hele tabel doorlopen is'.

De status "I" die was toegekend was onjuist (werd overschreven door de verwerkingssoort van het PKKX Tekstbestand die aan PKKO gekoppeld is), en daardoor mogelijk ook de verdere afhandeling van de PKKO tabel. Iets wat nu bij mij niet fout gaat omdat ik maar met één relatie-id test, maar bij jouw wel, omdat jij een hele reeks relaties erin hebt gezet om om te nummeren.

Zojuist de aanpassingen overgezonden, ik zou zeggen 'probeer het nog eens'. :wink:

Ok, bedankt!
Komend weekend ga ik nogmaals een kopie van Produktie > Test-omgeving maken en de lijst met relatie-id's nogmaals testen.

1 ding vind ik wel wat lastig in deze procedure: je moet de sleutelwijzigingen stuk voor stuk toevoegen, waarna je in de Test kunt controleren of het goed gaat. Wanneer je echter in produktie de wijzigingen definitief wil doorvoeren, moet je nogmaals de te wijzigen sleutels opnieuw toevoegen.
Is er geen trucje om dit minder bewerkelijk te maken?

Daar kan ik je niet anders dan gelijk in geven.

V.w.b. SY hebben we maar één database, er is geen verschil tussen Test- of Produktie. Vandaar dat er bij de Sleutelwijzigingen ook een optie is om de SY database over te slaan. Dit, omdat je weliswaar iets kunt omnummeren in Test, maar v.w.b. de SY bestanden nummert hij het ook om in je Produktiedatabase.

Tsja... een truc kan zijn:

a. de Sleutelwijzigingen op te nemen
b. SYCL, SYCK te kopieren
c. Sleutelwijzigingen testen in Test, doch zonder SY
d. als alles gelukt is, de oude SYCL en SYCK weer terugzetten, en dan in produktie uitvoeren.

We zullen eens nadenken over een échte oplossing :smile: