Geen onderhoudskosten voor een Office Programs Access applicatie
Of er wel of geen onderhoudskosten voor uw Access database zullen zijn, is in hoofdzaak afhankelijk van de vakbekwaamheid en de eerlijkheid van de ontwikkelaar.
Op deze pagina wordt uitgelegd waarom dat is en waar u op moet letten.
Behoed uzelf voor onaangename verrassingen
Bij het aanschaffen van een database spelen de kosten natuurlijk een belangrijke rol. En dat geldt zeker niet alleen bij de aanschaf! Daarom is het goed om uzelf deze vraag te stellen: 'Wat zijn de kosten op de langere termijn?' Voor u als leek is het antwoord op deze vraag natuurlijk nauwelijks of helemaal niet in te schatten, omdat u eenvoudigweg niet weet hoe een applicatie gebouwd zou moeten worden. Het gaat te ver om hier een cursus te geven. Bovendien zou dat aan het doel van deze pagina voorbij gaan. Het is echter wel goed mogelijk, en zelfs van groot belang, u hier te informeren welke zaken cruciaal zijn met betrekking tot de onderhoudskosten. Zo kunt u zichzelf, door deze informatie ter harte te nemen, behoeden voor onaangename verrassingen.
Aspecten die onderhoudskosten voorkomen
- Een ontwikkelaar moet in de eerste plaats een goede analyse maken van wat de wensen van de klant zijn. Ontbreekt deze vaardigheid of wordt daar te weinig tijd voor genomen, dan zullen delen opnieuw moeten of de applicatie werkt niet naar volle tevredenheid.
- Een ontwikkelaar moet met de klant meedenken en ervoor zorgen dat er met minder moeite en met minder kosten, meer rendement uit de applicatie gehaald zal worden. Als u niet alleen plaatjes kijkt maar ook de informatie doorneemt bij de vele voorbeelden op onze website, zult u daar een goed gevoel bij krijgen.
- Er mogen geen beperkingen zijn voor het invoeren van bijvoorbeeld het aantal klanten, facturen etc.
- Een applicatie heeft nooit een soort van 'onderhoudsbeurt' nodig in die zin dat dat speciaal door de programmeur moet gebeuren. Het enige dat van tijd tot tijd moet gebeuren is het comprimeren van de database. Access houdt namelijk geheugen vast van verwijderde records. Door te comprimeren wordt dat geheugen vrijgegeven. In een Office Programs Access applicatie is deze voorziening eenvoudigweg ingebouwd zodat u dit gemakkelijk zelf kunt uitvoeren.
- Er moeten zo weinig mogelijk statische objecten in de database aanwezig zijn zoals query's en rapporten. Dit laatste onderwerp in deze opsomming is voor een leek moeilijker te begrijpen, maar wel erg belangrijk. Daarom zullen we dit aspect hierna eens goed onder de loep houden...
Zo weinig mogelijk statische objecten
Met statische objecten bedoelen we 'vast omlijnde' objecten die (oorspronkelijk) telkens dezelfde informatie ophalen en geen andere vorm of lay-out aannemen, en geen verschillende (of geavanceerde) sets met records als resultaat kunnen geven. Rapporten en query's in een Access database zijn goede voorbeelden van statische objecten.
- Een rapport is een document dat informatie uit de database kan weergeven. Een rapport kan bijvoorbeeld informatie gegroepeerd weergeven, subtotalen en totalen berekenen etc. Zie voorbeeld 1, voorbeeld 2.
- Een query is een object dat informatie uit één of meerdere tabellen (of andere query's) verzamelt, desgewenst op basis van criteria, sortering, groepering etc.
Wanneer het de ontwikkelaar aan expertise ontbreekt om deze objecten met programmacode te manipuleren, is hij gedwongen meer en meer van dergelijke objecten te maken, met als gevolg hoge onderhoudskosten. Want als er iets verandert, moet dat vaak in tientallen, zo niet in honderden objecten worden doorgevoerd. Een Access database met veel rapporten en veel query's is dus geen reden om blij van te worden...
Een doorgewinterde programmeur echter, kan objecten als rapporten en query's, dynamisch maken. Met de juiste expertise kunnen ze gemanipuleerd worden zodat ze elke gewenste informatie ophalen en elke gewenste vorm of lay-out aannemen.
Zo kan één en hetzelfde rapport steeds op een andere recordbron (de bron waar de informatie in het rapport op gebaseerd is) worden ingesteld en kan de lay-out automatisch worden aangepast. Dit moet achter de schermen met programmacode gebeuren waarbij een beroep wordt gedaan op de expertise van de ontwikkelaar. In een aantal gevallen is het zelfs nodig de onderliggende bron van besturingselementen (de velden in het rapport) met programmacode te wijzigen of te verplaatsen. Hierdoor kan één rapport meerdere doelen dienen en geeft het de gebruiker meer mogelijkheden in zijn keuze. En dat is voor u erg prettig en kostenbesparend...
Een paar voorbeelden waarin query's en rapporten met geavanceerde programmacode worden gemanipuleerd:
- In dit voorbeeld ziet u hoe een gebruiker middels een dialoogvenster zelf kan bepalen hoe de lay-out van zijn factuur eruit moet komen te zien. Wanneer het rapport wordt afgedrukt of als er een afdrukvoorbeeld wordt gegenereerd, zal het rapport zich gedragen aan de hand van de instellingen die via dit dialoogvenster zijn ingesteld. Er worden nog veel meer zaken geregeld waardoor de af te drukken factuur een zeer dynamisch karakter krijgt, maar het is hier niet de bedoeling om u alle details van een specifiek rapport te tonen.
- In dit voorbeeld wordt een opdrachtbon afgedrukt waarbij erg veel mogelijkheden zijn. En daarvoor wordt slechts één en hetzelfde rapport gebruikt! Meer lezen over dit dialoogvenster...
- In dit voorbeeld wordt een urenoverzicht van werknemers afgedrukt. Ook weer een goed voorbeeld van ongelimiteerde mogelijkheden, gebruiksgemak en kostenbesparing. Meer lezen over dit dialoogvenster...
Waar u nog meer op moet letten
Het maakt niet zo'n fantastische indruk om negatieve zaken te belichten... Toch is het hier op zijn plaats om goed geïnformeerd te zijn teneinde veel narigheid en kosten te voorkomen. Gewoon omdat het op veel fronten binnen een gebouwde database mis kan gaan. Het is een kleine greep uit de analyses van databases.
- Relaties tussen tabellen zijn heel vaak niet correct ingesteld waardoor gerelateerde records niet meer aan elkaar gerelateerd zijn. Gevolg: dataverlies.
- Velden worden vaak niet gecontroleerd op invoer of op correcte invoer met alle gevolgen van dien waaronder dataverlies.
- Er zijn databases aangetroffen met meer dan 600 query's...
- Er zijn databases aangetroffen waarin voor elke ingevoerde klant een query moest worden gemaakt omdat er een bepaalde handeling voor elke klant moest worden uitgevoerd. Hierin heeft de ontwikkelaar zijn opdrachtgever wel erg afhankelijk van hem gemaakt... Of was dit misschien een lucratieve manier van penioenvoorziening???
- Voordat rapporten worden afgedrukt wordt niet gecontroleerd of de record is opgeslagen nadat deze is gewijzigd. Gevolg is dat het rapport niet de juiste informatie weergeeft.
- Gebruikers kunnen vaak gewoon bij het databasevenster waardoor zij objecten kunnen bewerken en data rechtstreeks in tabellen kunnen invoeren. Hierdoor kan er geen zekerheid worden verkregen dat de administratie gegarandeerd foutloos in orde is.
- Soms beperkt een applicatie het aantal in te voeren records zoals klanten en dergelijke.
- Er zijn de zogenaamde 'spaghetti programmeurs' die hun programmacode niet 're-useable' hebben gemaakt en overal in de database verschillend werken. Zij hebben geen gestructureerde manier van werken. Gevolg: hoge ontwikkelingskosten en vaak een andere toenadering vereist door de gebruiker.
- Een programmeur moet een applicatie dusdanig bouwen dat de klant, wanneer de database eenmaal klaar is, niet meer afhankelijk van hem zal zijn.
- En er zijn 'ontwikkelaars' die zich niet schromen geld te vragen voor het oplossen van hun eigen fouten. Ja, er zijn er zelfs die doelbewust bugs genereren om die vervolgens tegen betaling op te lossen...
Tot slot
Op deze pagina zijn slechts enkele voorbeelden gegeven die van cruciaal belang zijn om tot een goed resultaat te komen. Maar achter de schermen zijn er veel, veel meer aspecten waar een ontwikkelaar rekening mee moet houden. Het is niet nodig daar allemaal over uit te weiden. Hopelijk is hetgeen u nu hebt gezien en waarvoor u bent gewaarschuwd, voldoende om aan te nemen dat u de ontwikkeling van uw Access database maar beter aan een vakbekwaam iemand kunt overlaten. En dat deze persoon eerlijk en oprecht moet zijn om uw belangen te dienen en een grote mate van zorgvuldigheid in acht moet nemen, is wellicht eveneens zo klaar als een klontje...
Zie ook...
- De pagina Afdrukken van opdrachtbonnen.
- De pagina Handige dialoogvensters.
- De pagina Afdrukken Mandagenregister op werknemerbasis.
