Ik kom zojuist deze nog weer eens tegen, en konstateer dat het een beetje op een doodgebloed einde lijkt. Niets is minder waar;
Diverse mensen in den lande hebben op punt van ontslag (nemen, geven, dan wel krijgen) gestaan, komplete weekends zijn verworden tot uitgeregende trappelzakken (of hoe heet zo'n tenue waarmee je geen kwaad behoort te kunnen doen), echte - of zich zo noemende experts hebben getracht de mathematisch onomkeerbare puzzel the ontsluieren, mensen hebben spontaan hum mobieltjes in de plomp gegooid ...
Maar iets als dit kan maar beter nooit meer gebeuren. In elk geval niet als je 3 dagen na dato erachter komt dat e.e.a. niet helemaal is geslaagd (kwa ChangeKey) en je dus terug zou moeten naar een backup van 3 werkdagen eerder.
Achtergrond info voor eenieder (inklusief wij zelf) die meent dat iets als dit wel meer of slechts iets minder laconiek kan worden behandeld :
Men neme een willekeurige lijst (eigen vertaling) van produkten die je eigenlijk liever niet meer gebruikt; je geeft ze een ander Artikelnummer om moverende redenen (moverend is altijd een ietwat moeilijk woord, maar wordt in de juridische omgeving vooral gebruikt om aan te geven dat je nu eenmaal hebt gedaan wat je hebt gedaan en dat het JOU geen flikker uitmaakt waarom, en je vooral ook nooit naar de reden moet vragen, waarschijnlijk omdat je dat zelf niet weet, dan wel in tijdelijke staat van ontbinding bent geweest).
Je hebt die module ChangeKey toch, dus je denkt "kom", laat ik eens 2400 Artikelen gaan omnummeren. Vervolgens kom je erachter
dat de hoeveelheid eigenlijk niet is te overzien, dus je gebruikt dezelfde spreadsheet als waar je de oude meuk op vond, geeft deze aan Heart met de vraag of wij die opdrachten er op elektronische wijze in kunnen krijgen. "Tuurlijk, wij kunnen alles".
Zo gezegd do gedaan, en nadat de opdrachten erin staan hoeft de gebruiker nog slechts op F1 te duwen, om het systeem het werk te laten doen van het omnummeren. Tuurlijk doe je dit in de Testbestanden, want dat is immers voorschrift. Uiteraard kan je niet *alles* kontroleren, want dat is veulsteveul. En dus de handel ook maar in Produktie.
Twee dagen later konstateert iemand 2 keer hetzelfde Artikelnummer in het systeem, en geeft de opdracht om dit snel even op het forum te plaatsen; Heart weet daar wel raad mee.
Goed, wat hier verder dus niet is uitgeschreven, is dat de Excel met de erin te schieten opdrachten "fouten" bevatte. Kan gebeuren, en vergissen is menselijk. Het gevolg hiervan echter, is dusdanig drastisch dat het ook niet meer goed kan komen. Dus, in dit geval werd er omgenummerd naar reeds bestaande Artikelnummers, en werd de kontrole daarop niet (meer) uitgevoerd omdat die kontrole zich immers in het betreffende Toevoeg programma bevindt. En, gezien de konstruktie van het geheel kan dit ook in later stadium niet meer. Ze had natuurlijk moeten worden ingebouwd bij de tijdelijke (en "snelle") programmatuur die de Excel in de betreffende tabel in Profit schiet ... maar ja, als je zoiets moet gaan doen wordt iets wat ongeveer kosteloos is ineens heel erg duur, en meestal ook ondoenlijk.
Wel, in dit geval is de hoeveelheid om te nummeren niet alleen te groot om zelf in te typen v.w.b. de opdrachten, ze is tevens te groot om het reëlerwijs te kunnen kontroleren. Daarnaast - en dat is zo logisch als wat - wie gaat er nu kontroleren op een gegeven als "en bestond (!) het Artikelnummer soms al nadat de omnummering heeft plaatsgevonden". Tuurlijk niet, dat had al in eerder stadium moeten gebeuren.
En zo verziek je dus in één kleine handeling je hele database. Althans, als je dit pas merkt nadat de backup van een 3 dagen terug is dan kan je daar met recht over spreken.
Het is onduidelijk wie hiervan nu het meest in de stress heeft gezeten, de klant of wij zelf. Ik denk wij.
Merk ook op dat (dit erop neerkwam dat) dit een situatie was van het veranderen van de woordjes "de" in "een" in een tekst, waarna je vervolgens weer terug wilt naar de oude situatie, en denkt de woordjes "een" in "de" te kunnen veranderen. Dit GAAT ECHT NIET.
E.e.a. is nu "opgelost" door goede afspraken te maken (als er ergens iets vreemds gebeurt dan helpen wij wel) en verder door er pragmatisch naar te kijken, wat in dit geval goed mogelijk is (het betrof 20 reeds bestaande Artikelen die eigenlijk niet meer gebruikt moesten worden).
Goed, ik heb dit maar genoteerd omdat de mate van enerveren (t/m 5 dagen na de oorspronkelijke post) dat wel rechtvaardigt, maar vooral is het een poging om aan te geven dat er NOOIT lichtzinnig gedacht mag worden over ChangeKey en wat ze kan aanrichten. Daarom : Altijd eerst uitvoeren in de Testbestanden (en een verse kopie) *en* alles ook goed kontroleren. Zaken als het kontroleren op dubbele output hoort daar normaliter niet bij, maar ontstaat uiteraard al eerder : het juist bepalen van de nieuwe ID's (niet vergeten, het gaat niet alleen om Artikelnummers, maar theoretisch alles). Wij hebben intussen alles zo goed als mogelijk dichtgetimmerd, ook voor als er nog eens een spreadsheet langskomt in deze. Maar wat het laatste betreft geldt ook voor ons dat we - in het algemeen - niet zo maar zaken moeten inlezen, maar minimaal moeten (trachten te) kontroleren of wat de klant aanlevert wel juist is, en de hele handel niet om zeep kan helpen. Voor zo'n oordeel zou ik rustig twee uur extra rekenen, in plaats van te zeggen "oh, kwartiertje - half uurtje misschien". Starttarief.
Peter
Alle hier genoemde of geïmpliceerde personen zijn puur fictief doch berusten wel op een redelijke kern van waarheid.
