Met ingang van deze Releasenote is er een belangrijke aanpassing aangebracht in de werkwijze waarop Profit-Change-Key haar sleutels omnummert.
Per heden is er een nieuwe regel opgenomen in de koding, die zegt dat een Sleutelwaarde in een rubriek niet kan worden omgenummerd conform een index, waarbij de betreffende rubriek getrimd is opgenomen én niet als laatste veld in de index is opgenomen.
Een hele mond vol, en bij deze iets meer (technische) uitleg...
Bij het samenstellen van een index bestaat er de mogelijkheid om een veld getrimd op te nemen in de index. Hiermee worden alle overbodige spaties aan de rechterkant verwijderd, waardoor er feitelijk minder info in de index terecht komt (en deze niet onnodig groot wordt).
Dit trimmen mag echter niet zomaar ongestrafd overal worden toegepast; dit zou alleen maar mogen indien het betreffende indexveld tevens het laatste veld is in de index.
Kortom, stel dat we het Relatiebestand als voorbeeld nemen, dan hebben we een index op TRIM(LOSU_SID)+TRIM(LORE_RID). Omdat het Relatie-Id (LORE_RID) hier het laatste veld is in deze index, mag dit veld getrimd worden.
Betreft het om te nummeren veld niet het laatste veld in de index, bijvoorbeeld bij de index van een Ingekomen Faktuur (ADFI) alwaar er wordt omgenummerd via index 3:
TRIM(XXSU_SID)+TRIM(XXRC_RID)+TRIM(ADFI_FID)
dan zal een index niet uniek genoeg zijn, en kunnen we situaties kreëeren waarbij een Faktuur "012345" bij Relatie "ENCDEN" precies dezelfde sleutelwaarde oplevert als Faktuur "2345" bij Relatie "ENCDEN01".
Profit-Change-Key die op basis van deze indexen een sleutelwaarde gaat omnummeren kan hierop foutlopen, zonder dat op een simpele wijze achterhaald kan worden dát dit foutgelopen is. Zouden we volgens de index zoeken in de Fakturen naar Relatie "ENCDEN", dan zouden we eerst ENCDEN01+2345 kunnen vinden, waar er ook een ENCDEN+2000 bestaat. Zodra gekonstateerd wordt dat de Relatie niet meer voldoet, zal Change-Key denken dat ze klaar is, terwijl delen nog niet zullen zijn omgenummerd.
Nb: De oplettende lezer zal zien dat dus ook het éérste veld in de index, de bedrijfs-identifikatie, niet getrimd mag worden. Dat klopt, maar, v.w.b. de bedrijfs-identifikatie is er een regel gesteld die zegt dat we geen bedrijven mogen definiëren die kwa linkerdeel uit enkel bestaan. "HEART-A" <> "HEART-B" is toegestaan, omdat HEART-A niet voorkomt als linkerdeel van HEART-B (of andersom). Een bedrijf "HEART" naast een bedrijf "HEART-B" is echter niet toegestaan, omdat "HEART" als linkerdeel voorkomt in "HEART-B".
Her en der zitten er in het pakket nog indexen die niet conform deze regels zijn. In de afgelopen jaren zijn er al wel vaker massale konversies geweest waarbij indexen in het hele pakket door gewijzigd zijn, zoals recentelijk ook voor de tabellen ADBF en ADFI.
Per heden is Profit-Change-Key zodanig aangepast dat ze gewoonweg niet meer omnummert via een index waarbij het om te nummeren veld getrimd is opgenomen in de index. Dit, omdat theoretisch de mogelijkheid bestaat dat e.e.a. fout gaat. De betreffende index zal worden overgeslagen, en er wordt gezocht naar een volgende index. Is deze er niet, dan zal de tabel mogelijk sequentieel worden doorlopen.
Hierdoor zal Change-Key weliswaar voor die tabellen niet optimaal snel funktioneren, maar kan het niet meer (a.g.v. bovenstaande indexfout) foutlopen.
Zodra de situatie ontstaat dat er een sleutel in de oude situatie via een index omgenummerd zou zijn geworden, doch in de nieuwe situatie deze index overgeslagen werd omdat het betreffende veld getrimd in die index voorkwam, dan zal de Verwerkingssoort worden uitgebreid met de letter "T" (Trim).
Als we bovenstaand overzicht met het onderstaande vergelijken, dan zien we dat bijv. LOIA en ADFP tabellen zijn waarbij dergelijke Sleutelwijzigingen mogelijk verkeerd liepen.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| APCKDO | Omschrijving (nog) niet bekend | 13-10-2009 | 13-10-2009 |
