Gisteravond wilde ik het invoerdelen scherm verder uitbouwen, echter … wat schets mijn verbazing?! De compiler klapte eruit met een runtime error 0 bij het opstarten van het het programma! In eerste instantie verbazing. Nog maar eens starten … wel gloeiende, gloeiende, gloeiende … weer precies hetzelfde. Exact hetzelfde als op 29 februari en toen zakte de moed mij diep in de schoenen. Na nog een kort bericht op deze blog geplaatst te hebben (inmiddels verwijderd), heb ik moedeloos de PC uitgezet.
Vanmorgen kortstondig de boel nog maar eens bekeken. De zaken waren minder erg dan het de avond tevoren leek. Door het terugzetten van de backup (zie vorig bericht) waren ook links naar oude mappen weer terug in de compiler gezet. Het project van 29 februari werd weer geopend i.p.v. het meest recente. Ik slaakte een zucht van verlichting en startte het juiste project op. Ook dat verliep niet geheel vlekkeloos, maar gaf in ieder geval niet de runtime error 0. Verder kon ik vanmorgen niet kijken in verband met het werk. Pas in de middag kon ik weer kijken. Ik heb de backup van het project (net voor het defect raken van de SSD gemaakt) terug gezet en nu werkt alles weer naar behoren. Ik kan dus nu (eindelijk) weer verder.
Het maken van een backup wordt veelal een goede gewoonte genoemd. Eigenlijk is het niet gewoon een goede gewoonte maar iets wat net zo essentieel is als eten of drinken. Het aantal malen dat ik mensen sprak die dit nagelaten hadden en nu met de handen in het haar zaten, is niet op twee handen (en voeten) te tellen. Veel mensen vinden het een vervelend klusje omdat het tijd kost; tijd die men liever voor andere zaken gebruikt.
Men geeft zich geen rekenschap van het gemak, het voordeel en tijdsbesparing dat een backup oplevert.
Een calamiteit komt zelden gelegen en altijd op het moment dat men het niet verwacht. Het overkwam mij drie dagen geleden (weer eens) een keer. De SSD waarop mijn besturingssysteem (Windows XP) stond, gaf plotseling de geest en daar zat ik dan met een PC die niet meer kon opstarten. Geen besturingssysteem en dus geen mogelijkheid om allerlei zaken aan te passen of veilig te stellen.
Maar …… er was wel een backup van het besturingssysteem. Het terugplaatsen hiervan duurde slechts 20 minuten en alles was weer zoals het was. Twintig minuten tegenover twee dagen (wanneer alles weer opnieuw geïnstalleerd moet worden). Een tijdsverschil dat een maandelijkse backup ronde toch zeker lonend maakt.
Voor echt kritische bestanden kan men ook gebruik maken van Dropbox, waardoor men altijd de meest actuele versie van de bestanden zeker stelt.
Het kan toeval zijn maar ik vraag mij af of de bestandsproblemen van twee maanden geleden soms de eerste indicatie waren van de SSD problemen. Overigens hebben de DDH bestanden ditmaal op geen enkel moment risico gelopen. Van alle bestanden bestaan meerdere backups o.a. via Dropbox.
In eerste instantie was er maar weinig voortgang. Dit kwam voornamelijk doordat er in het (DNH) programma heel veel routines worden aangeroepen. Daarnaast wordt er in die procedures op gerekend dat er veel records in de diverse tabellen zitten. Normaal gesproken kan een programmeur ofwel uitgaan van een skelet waar een functie aan wordt toegevoegd ofwel heeft hij de beschikking over een (grote) hoeveelheid (test-) data. In dit geval ontbreken in het programma voor DDH nog steeds een groot gedeelte van die procedures en zijn diverse tabellen nog maagdelijk leeg. Dat maakte het programmeren een stuk lastiger. Met wat (tijdelijke) hap-snap oplossingen is nu m.b.v. het invoerhoorspelscherm het eerste hoorspel record toegevoegd. De procedure voor het automatisch zoeken en aanvullen in het titelveld kon daardoor worden toegevoegd, waardoor het zoeken en tonen van de gegevens in het hoorspelrecord weer kon worden toegevoegd. Het bijwerken van deze gegevens via het invoerhoorspelscherm kan nu worden geprogrammeerd. Vermoedelijk (of beter: hopelijk) zal dit niet veel tijd en denkwerk vergen. In essentie zou dit analoog moeten zijn aan het invoeren van een nieuw hoorspelrecord; de velden zijn nu gevuld i.p.v. niet leeg. Vervolgens kan er gewerkt worden aan het invoeren van de gegevens van de delen.
Sinds het laatste bericht zijn er twee schermen gereed gekomen. Beide schermen maken het mogelijk om alle gegevens omtrent hoorspelen in te voeren. Gaandeweg neig ik steeds meer tot het niet mogelijk te maken voor gebruikers van DDH om gegevens te wijzigen. Slechts een enkele gebruiker maakt op dit moment gebruik van die mogelijkheid in DNH. Verreweg de meesten gebruiken DNH als naslagwerk. De mogelijkheid WEL toevoegen aan DDH houdt veel extra programmeerwerk in.
Mogelijk zullen de gebruikers daarom nooit in aanraking komen met deze schermen, maar aangezien het essentiële schermen zijn voor de invoer van gegevens maak ik er toch melding van.
In DNH worden veel gegevens opgeslagen in ieder hoorspelrecord, bij DDH zal dat veel minder zijn. Veel van de gegevens zijn overgeheveld naar de records van de delen. Enerzijds is hierdoor de kans op foutieve redundantie veel kleiner, anderzijds kunnen hierdoor juist meer relevante gegevens bij een hoorspel worden opgeslagen.
Het hoorspel-invoer-scherm
Zoals duidelijk te zien is in de afbeelding, worden bij het hoorspel alleen de hoogst essentiële gegevens opgeslagen. Alle, bij het hoorspel, betrokken personen worden nu via het delen-invoer-scherm ingebracht. Door personen te koppelen aan delen in plaats van aan het hoorspel wordt aan de werkelijke inspanningen van personen veel meer recht gedaan met name bij hoorspelen waar iemand zijn functie niet bij alle delen heeft uitgeoefend. Dit heeft natuurlijk wel tot gevolg dat het delen-invoer-scherm erg complex geworden is.
Het delen-invoer-scherm
Om de beschrijving niet al te lang te maken volsta ik met te zeggen dat het hetzelfde zal werken als bij DNH en noem slechts de verschillen.
Opnamedatum, Duur, Trefwoorden en Muziek zijn nieuwe velden. Trefwoorden is toegevoegd om het zoeken naar een specifiek hoorspel te vergemakkelijken (bij zoeken op een trefwoord zal ook worden weergegeven welk deel het betreft. Muziek is iets wat veelvuldig in hoorspelen wordt gebruikt, niet alleen als begin- of eindtune maar ook om een pauze in te lassen of de spanning op te bouwen. Vaak is niet bekend welk muziekstuk wordt gebruikt (of uitvoerenden etc.) In de gevallen waar iets betreffende de muziek bekend is, zal dat in het betreffende veld worden ingevoerd.
In de tabel Uitzendingen staat nu naast kanaal ook omroep vermeld. Soms wordt een bepaald hoorspel herhaald door een andere omroep dan die het heeft opgenomen. In dit veld kan een dergelijk afwijking worden opgetekend.
Ondanks diverse pogingen om toch te ontdekken wat er nu precies misging, ben ik niets wijzer geworden omtrent de oorzaak. Het is nu, drie weken later, niet zinvol meer om verder nog pogingen in die richting te ondernemen. Dat boek is nu gesloten en zal alleen nog geopend worden indien het zich nogmaals voordoet (wat ik vanzelfsprekend liever niet zie gebeuren).
In de afgelopen dagen is het Personenscherm afgebouwd voor zover op dit moment mogelijk is. Alle functies, zolang ze niet de hoorspellijsten op het personenscherm betreffen, zijn nu geprogrammeerd, zelfs functies die voor het gesloten boek nog niet waren geprogrammeerd. Een van de laatste zaken die nog mogelijk moest worden gemaakt was het tonen van de artikelen die gelinkt zijn aan de betreffende persoon. Hieronder het betreffende artikel scherm.
Het artikel scherm
Het Invoerpersonenscherm is nu voor 100% afgebouwd. In dit scherm is nu ook de mogelijkheid ingebouwd om artikelen aan een persoon toe te voegen of te verwijderen. Het scherm heeft daardoor nog wat wijzigingen ondergaan, maar in de grote lijnen is het gelijk gebleven. Alle persoonlijke informatie omtrent personen kan hier nu worden ingebracht en/of gewijzigd. Mogelijk komt hier later toch nog twee extra functies bij, namelijk voor het onderhouden van de bestanden van de stemfragmenten en foto’s. Essentieel zijn deze functies niet aangezien dit ook buiten het programma om geregeld kan worden. Vooralsnog voeg ik ze nog niet toe. Hieronder het nieuwe invoerpersonen scherm.
Het nieuwe invoerpersonen scherm
Het herstel van de programmatuur, dat gisteren grotendeels werd afgesloten, moest natuurlijk getest worden. DIt is gisteren gedurende vier uur gedaan, door middel van het invoeren van gegevens van personen voor wie nog geen (of onvoldoende) gegevens in de database stonden. In die periode werd nog een kleine onvolkomenheid gevonden en gecorrigeerd. De gegevens werden naar behoren opgeslagen en waren ook weer foutloos oproepbaar. De gegevens die door de problemen verloren waren gegaan, zijn hierdoor wederom ingevoerd. In het geheel hebben de problemen een tijdverlies van ongeveer twee weken veroorzaakt.
Gisteren leek het er op dat er weer vanaf nul begonnen zou moeten worden. Vanmiddag lukte het bij een laatste poging om toch een deel van de oude programmatuur weer werkzaam te krijgen en daarmee loonde het de moeite om toch de trukendoos nogmaals open te trekken. En grotendeels met succes! Niet alles kon hersteld of gered worden. Zo zal bijvoorbeeld het scherm om hoorspelen in te voeren opnieuw moeten worden gebouwd en zijn alle persoonsgegevens die de laatste werkzame dagen waren ingebracht verloren gegaan. Positieve noot daarbij is wel dat de foto’s van de desbetreffende personen wel bewaard zijn gebleven. De status van het project is nu zo ongeveer die van twee weken geleden. Hoewel het vervelend is om bepaalde zaken nu opnieuw te moeten doen, geeft het gelukte herstel veel motivatie om verder te gaan.
Bij al dit positieve nieuws is er nog steeds wel een negatief punt. De vraag – Wat heeft de vorige problemen veroorzaakt? – is nog steeds niet beantwoord. Dat blijft reden tot zorg, ook al zal herstel, mochten de problemen zich nogmaals voordoen, minder tijd kosten dan tot nu toe.
In de afgelopen twee dagen heb ik een aantal mogelijkheden uitgeprobeerd in de hoop daarmee het programma toch weer draaiende te krijgen. Geen van die pogingen heeft veel soulaas geboden. Visual Basic blijft er uit knallen met foutmeldingen zodra ik het hele project opstart. Een aantal losse onderdelen veroorzaken geen probleem (ik heb niet alle onderdelen getest), maar zoals eerder gemeld, het geheel veroorzaakt die wel. De enige mogelijkheid die ik nu nog zie is opnieuw te beginnen. Maandag begin ik daarmee. DDH0 is een doodgeboren kindje.
Nadat de problemen zich gisteren (voor het eerst) voordeden, zat ik in eerste instantie met de handen in het haar. Dat verhielp (zoals te verwachten was) natuurlijk de problemen niet. Dus haalde ik de handen uit het haar en zette ze aan het werk op het toetsenbord. Ik begon met het op internet nazoeken van vergelijkbare toestanden/situaties en ik heb er zowaar een aantal gevonden. De bezochte pagina’s doen vermoeden dat er een probleem is gerezen met een van de programmeerelementen. Vreemd genoeg doet ‘het probleem zich in het geheel niet voor met andere programma’s die ik in het verleden heb geprogrammeerd (zoals DNH). Die werken gewoon zoals voorheen, zowel gecompileerd of als source code. Het ontstane probleem moet dus meer dan één oorzaak hebben. Dat wordt bevestigd doordat het terugzetten van een oudere back-up van Windows geen oplossing bood. Op dit moment schijnt dat het opnieuw opbouwen van het project de enige oplossing is, dus alle schermen en programmaregels zullen in een nieuw project opnieuw moeten worden gecodeerd. In eerste instantie ga ik nu proberen of het mogelijk is om gedeeltes van het oude project over te nemen. Als dat lukt, dan blijft de schade waarschijnlijk beperkt tot een week tijdverlies. Als dat niet kan, dan zal ik weer van voren af aan moeten beginnen (een vooruitzicht wat mij niet bepaald aanlokt).
Het meest vervelende aan deze situatie is dat de oorzaak van de problemen onduidelijk is en blijft. Het risico is daardoor niet in te schatten of het zich nogmaals kan voordoen.
AANVULLING:
De eerste tests leken in de richting van een I/O module van Microsoft te wijzen, echter na verwijdering hiervan bleef het probleem zich toch voordoen. Het raadsel wordt groter en groter …..
Om een geheel onbekende reden is het project corrupt geraakt. Alle schermen waar wat meer onderdelen op staan weigeren goed te laden en in sommige gevallen vliegt zelfs de programmeertaal er uit.
Aangezien ik geen flauw benul heb wat er gebeurd is en hoe ik dit op kan lossen (zelfs niet eens of dit wel op te lossen is, staat de hele boel dus vanaf nu compleet stil.
