Sleutelwijziging - Nieuwe waarde komt al voor (SYCKTV)

[pascal]

De module ChangeKey inmiddels getest met verschillende identiteiten in de Test-omgeving, dit gaat bijzonder goed.
We lopen echter tegen het volgende probleem aan:

menu 9-5-5-1 F4 Toevoegen Sleutelwijzigingen zoals op schermafdruk, met een Nieuwe waarde die al bestaat.
Er verschijnt een melding 'Nieuwe Waarde DURENT komt al voor in LORE'. Heel goed, want het overschrijven/samenvoegen van 2 identiteiten wil je normaal gesproken niet.

Maar nu hebben wij de situatie dat voor een heleboel relaties die verhuisd zijn, een nieuwe identiteit is gemaakt en waarbij de oude is blijven bestaan (maar niet meer wordt gebruikt). De historie zit echter wel in de oude identiteit; het zou mooi zijn wanneer we deze kunnen samenvoegen in de nieuwe identiteit.
Dus in dit geval is DURRYS verhuisd van RYS naar ENT (DURENT); DURRYS bevat zeer veel historische gegevens die je in DURENT niet terugvindt. Vandaar dat we deze historie graag willen kopieren (samenvoegen) naar de nieuwe identiteit.

Is het mogelijk dat de waarschuwing behouden blijft (LET OP: Nieuwe waarde komt al voor in LORE! Wilt u doorgaan?), maar dat je er wel voor kunt kiezen deze actie (bewust!) uit te voeren?
Want ongeacht of je een identiteit wijzigt of samenvoegt, een backup van de database is sowieso een voorwaarde (er kan van alles fout gaan).

[Peter Stordiau]

Nou, jij bent lekker zeg. Had die module dan aangeschaft voordat de mensen die nieuwe Relaties aanmaakten ...

Eigenlijk moet ik Nee zeggen, domweg omdat het niet is te overzien wat er dan gebeurt. Ook technisch is dat niet te overzien, alhoewel ik wel zeker weet dat er overal in deze relatief complexe programmatuur aanpassingen zullen moeten komen. Immers, bij jouw wens kan alles al bestaan, en niets gaat daar van uit. De enige kontrole die erin zit is die op de hoofdentiteit (= LORE) wat natuurlijk in de normale situatie ook voldoende is.

Al typend weet ik eigenlijk het antwoord al wel : dit gaat fout.
De programmatuur is immers niet intelligent, in die zin dat ze weet waar meer records mogen voorkomen, en waar slechts één. Bijvoorbeeld, aan de ene kant heb je bijvoorbeeld LORD waar duidelijk maar 1 record mag bestaan (en dan mag je ook nog kiezen of de oude of nieuwe overschreven moet worden (antwoord hoef ik trouwens niet), en iets als Verkooporders wat er duidelijk meerdere mogen zijn. Nu kan ik nog wel overzien dat een "sleutel" hiervoor bepalend is (de sleutel van de Verkooporder zal nooit al bestaan, terwijl de sleutel van LORD wel al zal bestaan, en dus "niets doen" (of altijd overschijven, maar in elk geval niet nogmaals opnemen), maar ik denk dat er fuzzy situaties zijn waar het eigenlijk twee kanten op kan zonder dat dit technisch zichtbaar is. En in dat geval gaat het vanzelf fout.
Merk nog op dat je rariteiten kan krijgen met als voorbeeld de Kontaktpersonen. Ook al betreft dat niet de Relatie zelf, ook hier kan je bedenken dat de nieuwe Kontaktpersoon de oude moet vervangen of andersom, terwijl je nu óók nog de situatie hebt dat twee dezelfde mensen een ander ID hebben, en er dus twee keer in komen te staan. Geen ramp in dit geval, maar dat is ... dit geval.
In een gevalletje Afleveradressen komen we er zonder specifieke intelligentie al niet meer uit, omdat je in beide gevallen zal zijn begonnen met met de nummering vanaf 1, maar uiteraard 1, 2, 3 enz. niet voor dezelfde adressen zullen staan. In zo'n geval de set van de ene maar achter de andere plaatsen met additionele nummers ?

Na voor mezelf zo'n geval gezien te hebben, moet ik helaas afhaken. Immers, dit betreft een oplossing die moet zegen IF AfleverAdres en ook al kan dat, er zijn er zo nog vast honderden, en die ken je pas als het is foutgegaan. En dat weet je in 90% van de gevallen als het te laat is (namelijk, als je niet meer terugwilt naar de backup).

Nee dus.