Bibliotheek uitleenformulier maken

Goedendag,

Ik heb al een poos zitten tobben met een probleem. Ik wil een bibliotheekdatabase maken, dus om boeken uit te lenen. Nu heb ik de volgende tabellen al: Klanten, Boeken, Schrijvers (van de boeken) en Geleende Boeken. Het probleem is vooral deze laatste tabel. Ik heb deze tabel overal gelinkt met andere tabellen, niet alleen in de relaties, maar ook onder het kopje "Opzoeken" in de Veldeigenschappen. Deze tabel bestaat uit de volgende veldnamen: Geleend_ID (oftewel het boek wat geleend wordt), de Klant, en de weeknummers (deze bieb is maar 1maal in de week open, dus vandaar het weeknummer ipv de datum). Nu wil ik een formulier waar maar 1 keer de klant ingevoerd hoeft te worden en dat de boeken daarna 1 voor 1 ingevuld kunnen worden zonder dat de klant veranderd.
Ik heb dit al op verschillende manieren geprobeerd. Ik heb geprobeerd een formulier aan te maken, waar als je op de klant klikt, deze opgeslagen wordt in een Query, en je tegelijk doorgestuurd wordt naar een ander formulier, waar die klant direct uit de query opgehaald werd. Omdat je een formulier niet op een tabel en een query tegelijk kan linken, had ik de Klant uit de Geleende Boeken-tabel gelinkt onder het kopje "Opzoeken" in de veldeigenschappen, als een keuzelijst naar de query. Zo werd dus steeds als keuzelijst alleen de klant getoond die in het vorige formulier aangeklikt was. Een groot nadeel was wel dat de klant bij elk nieuw record opnieuw aangeklikt moest worden. Ik ben hier een poos mee getobd, maar ik vond nergens een optie om direct na het laden van het formulier het eerste record van de keuzelijst aan te klikken. Dit heb ik nog niet verwijderd, dus als iemand hier nog een antwoord op heeft, zou ontzettend fijn zijn (is dit iets in de VBA-code??)!
Ondertussen kreeg ik van iemand de tip om met een subformulier te werken, maar hier had ik nog sneller problemen mee. Hoe krijg je een subformulier waarin je records toe kan voegen? Ik krijg steeds de melding als ik eerst de klant invul dat ik het "Geleend_ID" in moet vullen, en als ik dat eerst doe, krijg ik de melding dat ik eerst de klant in moet vullen. Het lijkt wel of het formulier de record op wil slaan als ik van het hoofdformulier naar het subformulier ga. Misschien is het subformulier hier helemaal niet geschikt voor, zou ook nog kunnen.
Als er meer informatie nodig is, vraag het maar en ik probeer het zo snel mogelijk door te sturen.

Alvast bedankt,

Stef21

Allereerst welkom bij HelpMij .

Stef21 zei:

Ik heb deze tabel overal gelinkt met andere tabellen, niet alleen in de relaties, maar ook onder het kopje "Opzoeken" in de Veldeigenschappen.

Klik om te vergroten...

Dat laatste is een slecht idee, want in tabellen moet je geen opzoeklijsten gebruiken die zijn gebaseerd op tabellen. Ja ik weet, het, Microsof heeft het ingebouwd, dus dan mag jij het gebruiken... . Maar het is een heel slecht idee, dus niet doen. Keuzelijsten gebruik je op Formulieren, niet in tabellen.
Geleend_ID vind ik niet zo'n slimme naam, en wellicht moet je je structuur nog eens tegen het licht houden, want in je huidige constructie kun je van élk boek maar één exemplaar hebben/uitlenen. Dat lijkt mij een beetje mager voor populaire boeken. Dus ik zou in ieder geval een tabel extra maken waarin je de Boeken koppelt aan Stock (o.i.d.; de naam is uiteraard niet belangrijk. Zou bij jou eigenlijk [Te lenen Boeken] kunnen zijn).

Daarnaast maak je nóg een denkfout: de tabel [Geleende Boeken] lijkt mij niet correct. Een geleend boek is, zoals de naam al zegt, een tabel waarin je bijhoudt welk boek uitgeleend is. Het zegt niets over aan wie het is uitgeleend, noch welke ándere boeken aan dezelfde persoon zijn meegegeven.
Tussen de klant en [Te lenen Boeken] dient dus een extra tabel te komen, met een één-op-een relatie met zowel Klanten als één of meer records uit de tabel [Te lenen Boeken]. Laten we die tabel [Uitleen] noemen. Hierin leg je dus de KlantID vast, en (nooit weeknummers doen, weken komen elk jaar terug en wat doe je dan?) de uitleendatum. Deze tabel bevat dan een koppeling met [Uitgeleende boeken] waarin dus de ID uit de tabel [Uitleen] terugkomt, alsmede de BoekID's uit [Te lenen Boeken].

Zie het als een bestelling: een klant doet één bestelling, dus je vult één keer de KlantID in, plus de besteldatum etc. De tabel Bestellingen (uitleentransacties) koppel je aan de tabel BestellingRegels (uit te lenen boeken) op het BestellingID (UitleenID), en de te bestellen goederen (boeken) haal je dus uit de tabel Artikelen ([Uit te lenen boeken]). En ja, die tabel BestellingRegels is een subformulier op het formulier Bestellingen .

Daarnaast maak je een hoop denk/kennis fouten

Stef21 zei:

1. waar als je op de klant klikt, deze opgeslagen wordt in een Query
2. Omdat je een formulier niet op een tabel en een query tegelijk kan linken
3. Hoe krijg je een subformulier waarin je records toe kan voegen?

Klik om te vergroten...

Om maar eens drie punten uit je verhaal aan te halen die niet kloppen. Kortom: genoeg redenen om niet meer informatie te sturen, maar een kopie van de database. Staan daar al klantgegevens in, dan moet je die even anonimiseren, want daar hebben wij uiteraard niets mee te maken. Het gaat ons om de structuur van de database. Daar moeten dan wel voldoende boeken in zitten en klantgegevens om een beetje mee te stoeien.

En voordat je de verkeerde knop straks indrukt: de QUOTE knop is geen antwoordknop . Gebruik het tekstvak <Snel reageren> om een antwoord te typen, en als je de database bijvoegt: klik dan op <Ga geavanceerd> (anders kan het namelijk niet) en upload een gezipte versie van de database.

Bedankt voor het uitgebreide antwoord!

OctaFish zei:

want in je huidige constructie kun je van élk boek maar één exemplaar hebben/uitlenen. Dat lijkt mij een beetje mager voor populaire boeken. Dus ik zou in ieder geval een tabel extra maken waarin je de Boeken koppelt aan Stock (o.i.d.; de naam is uiteraard niet belangrijk. Zou bij jou eigenlijk [Te lenen Boeken] kunnen zijn).

Klik om te vergroten...

Ik denk niet dat dit een probleem zal zijn. Als er namelijk 2 of meer boeken komen, krijgen deze een ander nummer. Dit probleem speelt dus eigenlijk niet.

nooit weeknummers doen, weken komen elk jaar terug en wat doe je dan?

Klik om te vergroten...

De bibliotheek is niet elke week op dezelfde dag open. Dit is organisatorisch niet mogelijk, doordat deze zaal ook wel eens voor andere doeleinden gebruikt wordt. Straks wil ik direct aangeven hoeveel het kost om het boek te lenen. Dit gaat per week, dus vandaar dat ik het weeknummer wil gebruiken. De betaling gebeurt dus achteraf. Ik zou wel het jaarnummer met daarna het weeknummer, of andersom, kunnen doen, dan heb ik dat probleem niet, toch?

De tweede alinea: Goed idee, ga ik mee aan de slag. Zodra dit af is en ik nog wat kleinigheidjes weggewerkt heb, zal ik het programma doorsturen.

OctaFish zei:

Daarnaast maak je nóg een denkfout: de tabel [Geleende Boeken] lijkt mij niet correct. Een geleend boek is, zoals de naam al zegt, een tabel waarin je bijhoudt welk boek uitgeleend is. Het zegt niets over aan wie het is uitgeleend, noch welke ándere boeken aan dezelfde persoon zijn meegegeven.
Tussen de klant en [Te lenen Boeken] dient dus een extra tabel te komen, met een één-op-een relatie met zowel Klanten als één of meer records uit de tabel [Te lenen Boeken]. Laten we die tabel [Uitleen] noemen. Hierin leg je dus de KlantID vast, en (nooit weeknummers doen, weken komen elk jaar terug en wat doe je dan?) de uitleendatum. Deze tabel bevat dan een koppeling met [Uitgeleende boeken] waarin dus de ID uit de tabel [Uitleen] terugkomt, alsmede de BoekID's uit [Te lenen Boeken].

Klik om te vergroten...

Dit doe ik toch? Bij mij heet deze tabel dan Geleende Boeken, maar als ik het een andere naam geef, zoals [Uitleen], dan is dat volgens mij precies hetzelfde als wat ik al heb

Stef21 zei:

Ik denk niet dat dit een probleem zal zijn. Als er namelijk 2 of meer boeken komen, krijgen deze een ander nummer. Dit probleem speelt dus eigenlijk niet.

Klik om te vergroten...

Tuurlijk krijgen ze een ander nummer, maar het is hetzelfde boek, met dezelfde auteur, dezelfde uitgever, hetzelfde ISBN nummer, etc. Kortom: hetzelfde item, maar dan in meerdere uitvoeringen. En élke uitvoering wordt apart uitgeleend. Het kan natuurlijk best zijn dat in een kleine bibliotheek volstaan kan worden met één of twee exemplaren van een boek, maar dan beperkt je de database al op voorhand van de mogelijkheid om snel doeltreffend en effectief te kunnen werken als er wél wordt uitgebreid. Kortom: beetje oogkleppen op . Dus een probleem wat nú niet speelt, kan dat in de toekomst wél zijn. En wat is er op tegen om de database daar al op voor te bereiden? Het maakt voor je huidige database namelijk hoegenaamd niets uit in de werking of het bedieningsgemak als je het in één keer goed doet. Kortom: wat heb je er op tegen om het gelijk goed te doen?

Ook je verklaring om weeknummers te gebruiken snijdt geen hout. Dat argument gaat alleen op als je een specifieke week nooit meer gaat gebruiken. Dat de bibliotheek maar één dag in de week open is, doet niets af aan het feit dat die het jaar daarop waarschijnlijk gewoon weer in dezelfde week óók weer open is. Verder geldt ook hier: wat is er op tegen om het gelijk goed te doen, en wél met een datum te werken? Júist als de bibliotheek maar één dag in de week open is, kun je met een standaardwaarde heel goed gelijk al de huurdatum laten invullen, want dat is altijd de datum van vandaag. Bovendien: als je de datum weet, weet je óók het weeknummer want dat is een afgeleide van de datum, en heel makkelijk te berekenen. Alle berekeningen die je zou doen op weeknummers kun je dus net zo makkelijk óók doen als je de datum hebt opgeslagen.

Ik krijg de indruk dat je de hele opzet nog niet goed hebt doorgedacht, en veel te kort door de bocht gaat. En dat is de grootste fout die je bij het maken van een database kan maken .

Ik krijg op dit moment erg veel nieuwe inzichten. Dit is natuurlijk helemaal niet erg.
Dit is mijn eerste grote database die ik maak, dus vandaar dat er wat kennis mist. Ook heb ik in mijn omgeving niet zo makkelijk iemand die er goed bij kan helpen. In ieder geval heb ik alles op een rij gezet voordat ik begon: Wat wil ik hebben, welke tabellen heb ik nodig en de relaties daartussen en wat zal ik ongeveer aan formulieren moeten gebruiken. Ik heb dus wel wat voorbereiding gedaan, maar ik heb blijkbaar niet aan alles gedacht.

maar dan beperkt je de database al op voorhand van de mogelijkheid om snel doeltreffend en effectief te kunnen werken als er wél wordt uitgebreid

Klik om te vergroten...

Misschien lijk ik nu heel dom, maar ik snap eerlijk gezegd het probleem nog steeds niet zo. Als er een boek is met dezelfde titel, dezelfde schrijver, alles hetzelfde behalve het ID (wat de bieb zelf bedenkt), waarom zou er dan een probleem zijn bij het uitlenen van de boeken? Het boek wordt toch uitgeleend op basis van boeknummer?
Wat ik wel kan en wil doen is een formulier waar ze een boek op kunnen zoeken op basis van titel, en dan moet ik inderdaad rekening houden dat er meerdere boeken met die titel zijn.

Alle berekeningen die je zou doen op weeknummers kun je dus net zo makkelijk óók doen als je de datum hebt opgeslagen.

Klik om te vergroten...

Dit is dus zoiets waar ik zelf nooit aan gedacht zou hebben, en wat ik dus ga oplossen!

Stef21 zei:

In ieder geval heb ik alles op een rij gezet voordat ik begon: Wat wil ik hebben, welke tabellen heb ik nodig en de relaties daartussen en wat zal ik ongeveer aan formulieren moeten gebruiken.

Klik om te vergroten...

Dat is desalniettemin de verkeerde volgorde. Het is heel goed om een Plan van Aanpak te maken waarbij je nadenkt over wat je wilt hebben. Daarbij moet je dus zoveel mogelijk van te voren bedenken wat je uit het systeem wilt kunnen halen. Daarbij ga je dus zéker niet over tabellen nadenken, en al helemaal niet over formulieren; dat komt pas veel later. In eerste instantie is het veel nuttiger om, een beetje ala agile, a.d.h.v. user stories te bepalen wat de activiteiten zijn die je vast wilt leggen, en wat daar de output van moet zijn. (Bijvoorbeeld: medewerker moet een klant moet meerdere boeken kunnen uitlenen zonder dat elk boek apart ingeschreven wordt als aparte uitleentransactie. Of: populaire boeken moeten in grote getale kunnen worden aangeschaft en ingeboekt en uitgeleend kunnen worden). Daar volgen processen uit, en die ga je vertalen naar tabellen. Als je dat voor ogen hebt, ga je kijken welke tabellen je daar voor nodig hebt, en welke informatie daarin moet worden opgeslagen.

Wat betreft je vraag over de boeken: ja, natuurlijk kun je voor elk boek een volledige administratie invullen, maar dan doe je dus dubbel werk. Daarnaast is het een enorme risicofactor, want het is bijzonder eenvoudig om bijvoorbeeld een auteur van een boek verkeerd te spellen. Of, bij een boek met meerdere auteurs, de auteurs niet volledig in te vullen. Daarmee heb je voor je gevoel dan beide (of nog meer) exemplaren in de boekhouding staan, maar voor het systeem zijn het niet dezelfde boeken. Omdat de onderliggende gegevens niet overeenkomen. Alleen dát aspect al zou je over de streep moeten trekken! In technische termen heet dat: dataredundantie. En dat moet je zoveel mogelijk zien te voorkomen. Op het moment dat je constateert dat je (al dan niet vaak) dezelfde gegevens steeds opnieuw aan het invoeren bent, en dat ga jij dus doen, dan klopt het systeem niet. Het is dus vele malen beter om de gegevens van één object maar één keer vast te leggen (in de tabel Boeken) en voor de afzonderlijke exemplaren dus aparte records te maken waarin je de hoofdgegevens van het boek dus uit de tabel Boeken haalt.

Dát proces heet 'normaliseren' van je database, en dat is eigenlijk de grondslag van een database die vanaf dag één op de toekomst is voorbereid. Nogmaals: jouw opzet is dat dus niet. Ik kan dat niet genoeg benadrukken . En het maakt de database dus niet ingewikkelder in het gebruik, alleen maar makkelijker .

Volledige administratie... Ik ken inderdaad het proces normaliseren van de database. Dat doe ik op de volgende manier: De schrijvers die bij de boeken horen, kunnen enkel en alleen aangeklikt worden, dus niet veranderd. Er kan allicht wel een schrijver toegevoegd worden, als er een nieuwe schrijver in de bibliotheek komt. Alleen bij dat laatste kunnen fouten gemaakt worden (maar dan zou je spellingscontrole moeten gaan gebruiken om dat op te lossen). De boeknummers worden tot nu toe zelf gekozen, maar waarschijnlijk gaat dit veranderen en wordt er met een streepjescode gewerkt. Daar heb ik het op gebaseerd, dat er zo weinig mogelijk fouten gemaakt kunnen worden.
Het zwakste punt van mijn database is het invoeren van nieuwe boeken en dat besef ik, maar ik ga daar geen spellingscontrole op invoeren, dat werkt natuurlijk niet. De schrijver wordt dus door te klikken ingevoerd. Het onderwerp wordt ook door een keuzelijst beperkt.
Merk ik nou uit uw woorden dat ik als er een nieuw boek bijgevoegd wordt, ik eerst moet vragen of het lijkt op een ander boek wat al in de bieb staat? Dit is toch veel te omslachtig, aangezien er veel meer nieuwe boeken binnenkomen die niet dubbel zijn, als dat er zijn die wel dubbel zijn? Ik weet niet of dit veel voordeel heeft ten opzichte van het nadeel dat je steeds die vraag moet wegklikken, wat op den duur leidt dat je het automatisch weg klikt zonder zelfs maar te kijken en na te denken wat er staat en dus ontstaan er alsnog fouten.

Morgen stuur ik het bestand door!

Stef21 zei:

Merk ik nou uit uw woorden dat ik als er een nieuw boek bijgevoegd wordt, ik eerst moet vragen of het lijkt op een ander boek wat al in de bieb staat? Dit is toch veel te omslachtig, aangezien er veel meer nieuwe boeken binnenkomen die niet dubbel zijn, als dat er zijn die wel dubbel zijn?

Klik om te vergroten...

Volgens mij heb je het normalisatie proces niet helemaal door; kijk eens in de Handleidingen sectie van Helpmij, daar staat een prima (ahum) cursus Access, waar ik begin met het Normalisatie proces uit te leggen. Auteurs horen inderdaad in een aparte tabel, zodat je ze maar één keer hoeft in te voeren, en daarna kan kiezen bij de boeken die ze hebben geschreven. Dat is dus wél een stukje normalisatie . Spellingcontrole op boektitels? Lijkt mij onzinnig. Zou niet eens bij me opkomen .

Stef21 zei:

Het zwakste punt van mijn database is het invoeren van nieuwe boeken en dat besef ik

Klik om te vergroten...

Controleren of een boek al bestaat? Wel wis en waarachtig! Dát is nu juist de kracht van een goede database dat je dat goed kunt afvangen. En voorkomen dat je veel dubbel werk doet, valt daar ook onder. Het toevoegen van nieuwe boeken doe je overigens ook behoorlijk geautomatiseerd, dus zonder dubbel werk. Maar dat komt later wel aan bod . Maar je controleert toch ook of een nieuwe klant niet al toevallig in het systeem staat? Wil je toch ook niet dubbel hebben? Zwakke punten horen niet thuis in een goede database, en juist dit onderdeel kun je perfect regelen. Doe dat dan ook. Zodra je gaat denken: 'dat is extra werk' ben je in mijn ogen verkeerd bezig. Je moet denken: wat is nodig om de database foutloos te laten werken. En daar volgen bepaalde acties uit. En die kun je ook prima verdedigen naar de gebruikers toe.

Hierbij mijn bestand. Niet alles werkt nog helemaal feilloos, maar ik heb alles wat het niet meer deed er in ieder geval uit gehaald. De klanten die erin staan zijn verzonnen.

Ik zal er naar kijken!

k heb er een beetje mee zitten stoeien, en het is nog verre van af, maar met deze db krijg je een beetje een idee welke kant ik op zou gaan.

Wow, ik ken mijn eigen database bijna niet meer terug. Hartelijk bedankt voor het werk wat u erin hebt gestopt! Ik ga ermee verder, en als ik weer op een probleem stuit, kom ik wel weer terug!

Ik doe ook maar wat hè . Ik ken jouw processen uiteraard niet, dus ik zou niet blindelings varen op wat ik er van gemaakt heb nu. Zo is er bijvoorbeeld nog niks geregeld voor eventuele betalingen, nieuwe klanten inschrijven, nieuwe boeken inschrijvingen. Klanten zou je moeten kunnen inschrijven vanuit het Uitleenformulier; normaal gesproken heb je dat standaard open staan omdat uitleningen de basishandelingen zijn van een bibliotheek. Een klant komt bijvoorbeeld met boeken naar de balie die geleend gaan worden. Een (nieuwe) klant zoek je dan op, en van daaruit kun je dan verder werken. Bij een nieuwe klant zul je die eerst in willen schrijven, en dat kan dus allemaal vanuit één formulier geregeld worden. Het zal zelden nodig zijn om heen en weer te schakelen tussen de verschillende formulieren. Dat regelt het programma dus.

Daarnaast zal een uitgeleend boek niet meer in de lijst mogen staan als je een nieuwe uitlening registreert; uitgeleende boeken zijn fysiek immers niet aanwezig in de bibliotheek, en je wilt voorkomen dat je een reeds uitgeleend boek nogmaals uitleent (althans: registreert als uitlening). Ook dát kan gemakkelijk geregeld worden, maar heb ik nog niet gedaan.

Bij onderhoudswerkzaamheden gebruik je een ander (inventarisatie)formulier, waarin je nieuwe boeken/auteurs/stock kan invoeren of afvoeren. Dan zou je dus, als je een nieuw boek met een nieuwe auteur opvoert, die auteur willen kiezen (bij reeds ingevoerde auteur) of opvoeren (bij nieuwe auteur). Ook dát is niet gemaakt. Kan dus allemaal behoorlijk automatisch geregeld worden. Dat hele proces is er dus op gericht om a) geen dubbel werk te hoeven doen en b) er voor te zorgen dat de informatie zo betrouwbaar mogelijk in het systeem wordt opgevoerd.

Maar nogmaals: de uitwerking van e.e.a. is dus zwaar afhankelijk van jouw processen. Zelf zou ik er nog een formulier tegenaan gooien waarin je ziet welke boeken overtijd zijn (uitleentermijn verstreken) zodat je eventueel geautomatiseerd mailtjes kunt sturen naar de klant. Je hebt waarschijnlijk ook al gezien dat ik wat velden uit tabellen heb verwijderd, waarvan ik vind dat ze niet in die tabellen thuishoren. Ook dát is een onderdeel van het normalisatie traject, waarbij je dus nadenkt over de verschillende objecten (klanten, boeken, medewerkers wellicht) en welke eigenschappen die objecten hebben. En als je daar goed over nadenkt, dan zie je vanzelf welke velden (attributen in database termen) iets zeggen over het onderwerp, en welke niet. Neem nu je tabel klanten: die bevat de velden [Boeken geleend] en [Uitstaande boete]. Beide velden horen niet thuis in een Klanten tabel, want het zijn geen velden die een eigenschap van een klant beschrijven. Een klant heeft een naam, een adres, een telefoonnummer etc. Dat zijn klantgegevens. Boetebedragen zijn variabel, en dat geldt ook voor geleende boeken. Dit zijn dus geen beschrijvende velden voor een eigenschap van een klant.
En zo heb je er dus veel meer. Wat je dus doet, is voor die velden aan eigen plek (eigen tabel, andere tabel) zoeken waar ze wél thuishoren. En zo bouw je dus de uiteindelijke wensen om naar een database .

Hoe heeft u het voor elkaar gekregen om het hoofdformulier en nog een aantal formulieren bij het openen in een nieuw venster te openen en kan dit ook automatisch full-screen? Ik heb al gekeken in het eigenschappenvenster en in de VBA-code, maar het lukte me niet.

Laat maar doen, ik had iets over het hoofd gezien in de eigenschappen :d

Stef21 zei:

Hoe heeft u het voor elkaar gekregen om het hoofdformulier en nog een aantal formulieren bij het openen in een nieuw venster te openen en kan dit ook automatisch full-screen?

Klik om te vergroten...

Persoonlijk ben ik geen voorstander van beeldvullende formulieren, omdat dat er (in mijn ogen dus, maar ik ben een design-fetisjist) vreselijk lelijk uitziet. De meeste formulieren zijn namelijk niet gemaakt voor een beeldvullende weergave, ook al omdat je geen controle hebt over de beschikbare ruimte: als iemand de navigatiebalk breder maakt, of een andere schermresolutie instelt, is je opmaak naar de ratsmodee. Ik maak dus formulieren die qua afmetingen kloppen. En dat altijd blijven doen. Maar laat dat je niet in de weg staan om het anders te doen. En wellicht heb jij het gouden ei van Columbus gevonden dat er voor zorgt dat een formulier er altijd perfect uit ziet .

Hallo,
Ik ben weer terug!
Ik heb inderdaad best wat veranderingen aangebracht in de database. Toen kwam ik weer op een probleem. Eigenlijk was dat probleem er al vanaf het moment dat ik de database overnam. Octafish heeft namelijk een Uitleen_ID toegevoegd, die ik uit de hele database wil halen. Dit komt doordat dit Uitleen_ID niet helemaal goed werkt. Het probleem was namelijk dat bij elke [Klant] er een nieuw [Uitleen_ID] aangemaakt moest worden in de database. Anders werden de boeken niet op naam opgeschreven, wat natuurlijk wel de bedoeling is. Ook heb ik dan een probleem bij het terugbrengen van de boeken. De bibliothecaris moet dan precies opschrijven bij welke [klant] welk [Uitleen_ID] hoort om dit weer kloppend te krijgen.
Wat ik wilde doen om dit op te lossen is het [Uitleen_ID] te verwijderen en de uitgeleende boeken op basis van het [Klant_ID] op te slaan. Ik heb dus overal het [Uitleen_ID] verwijderd, met natuurlijk een vorige versie waar ik altijd op kan terugvallen als het niet helemaal goed gaat, maar nu kan ik geen nieuwe boeken bijvoegen in het formulier. De foutcode die Access geeft: Het veld Naam (dit is gewoon de klant) is gebaseerd op een expressie en kan dus niet worden bewerkt.
Ik heb zoveel veranderd, ook in de structuur, dat het misschien handig is dat ik de database opnieuw doorstuur, dus bij deze:

Bekijk bijlage Bibliotheek ok.zip

Om in de database zelf te komen, kunt u direct op het kruisje klikken in het Hoofdmenu. De achtergrond ga ik nog een leuk kleurtje geven, dus het blijft niet saai wit
Andere formulieren kunt u sluiten door linksbovenin op de linker- of rechtermuisknop te klikken en daarna te klikken op sluiten.

Alvast bedankt!

Stef21 zei:

Octafish heeft namelijk een Uitleen_ID toegevoegd, die ik uit de hele database wil halen. Dit komt doordat dit Uitleen_ID niet helemaal goed werkt. Het probleem was namelijk dat bij elke [Klant] er een nieuw [Uitleen_ID] aangemaakt moest worden in de database. Anders werden de boeken niet op naam opgeschreven, wat natuurlijk wel de bedoeling is. Ook heb ik dan een probleem bij het terugbrengen van de boeken. De bibliothecaris moet dan precies opschrijven bij welke [klant] welk [Uitleen_ID] hoort om dit weer kloppend te krijgen.

Klik om te vergroten...

Probeer éérst te begrijpen welke verbeteringen ik heb aangebracht, voordat je besluit dat je het zelf tóch beter weet, want dat doe je niet .
En je verhaal klopt dus óók niet. Ik wil nog wel even kijken naar jouw nieuwe db, maar als die mij niet bevalt, sta ik niet te popelen om daar nog wat aan te doen, omdat míjn versie dus wél goed werkt, en verder naar jouw processen kan worden doorgebouwd. Het feit dat jij in jóuw versie gelijk het oorspronkelijke probleem hebt, wat je niet opgelost krijgt, zegt wat dat betreft al genoeg lijkt mij. Kortom: bestudeer éérst mijn versie, en probeer te snappen wat daar gebeurt. Zoals gezegd: ik kijk even naar jouw nieuwe versie. Gelukkig heb ik een goed gevulde drankkast

Sorry, het was echt niet mijn bedoeling om het af te kraken, er was ontzettend veel 'usefull stuff', maar sommige dingen waren niet precies zoals de bibliotheek werkt waarvoor ik de database maak. Ook wel logisch dat het niet helemaal perfect was, want u weet niet precies hoe onze bibliotheek werkt natuurlijk .
Toen ik de database kreeg heb ik inderdaad eerst goed gekeken hoe alles nu in elkaar stak, voordat ik begon met veranderen.
Ik weet trouwens dat ik het niet beter weet, want anders zou ik geen vragen stellen :d!

Wat ik alleen bijzonder vind is dat wat ik in het formulier [fBoekenUitleen] ook verander aan de klanten, de lijst met boeken veranderd niet. Zou dat dan niet betekenen dat het niets uitmaakt welke klant het leent, als het maar uitgeleend wordt?

Ik zal nog even uitleggen hoe onze bibliotheek te werk gaat:
Ik ben een klant en ik neem een hele stapel boeken mee. Die worden opgeschreven in de database op naam en daarna mag ik het meenemen. 2 weken later kom ik met drie boeken terug. Deze worden afgestreept van de lijst, en er wordt berekend hoeveel ik moet betalen, omdat ik die boeken twee weken meegenomen heb. Weer drie weken later kom ik met de rest terug. Nu worden deze ook afgestreept en moet ik daar geld voor betalen.
Uit de database die ik terugkreeg had ik namelijk het idee dat u dacht dat de bibliotheek zo werkte: Je betaalt vooraf voor het aantal boeken wat je meeneemt, deze krijgen een bepaalde leningstermijn, en als deze voorbij is, komt er een boete op de boeken. Dit zag ik omdat er een kolom uitleentermijn was.

Het geeft niet dat hier verschillen in waren, maar omdat ik het natuurlijk wel goed uit moet voeren voor specifiek onze bibliotheek, moet dit goed geregeld zijn vanaf mijn kant . Daarom had ik ook wat problemen met het formulier [fBoekenUitleen].

Alvast bedankt voor uw werk en als het niet lukt of u heeft er geen zin meer in: Ontzettend bedankt voor het duwen in de goede richting en de geïnvesteerde tijd in mijn database!

MVG,

Stef21

Bij het maken van een database moet je, als ontwerper, de procedures en processen kennen, ander moet je er niet eens aan beginnen. Wij, de helpers, kennen die niet, dus wij moeten het doen met de informatie die jij ons geeft. Dus dat verklaart waarom je tips krijgt waar je wellicht niets aan hebt. Is niet onze schuld, maar komt dus door een gebrek aan informatie.

Stef21 zei:

Wat ik alleen bijzonder vind is dat wat ik in het formulier [fBoekenUitleen] ook verander aan de klanten, de lijst met boeken veranderd niet. Zou dat dan niet betekenen dat het niets uitmaakt welke klant het leent, als het maar uitgeleend wordt?

Klik om te vergroten...

Dat zie je dus verkeerd. Boeken uitlenen is een transactie, waarbij je een aantal gegevens vastlegt. Welke, dat bepaalt natuurlijk degene die achter de toonbank staat. Zodra een transactie is vastgelegd, liggen de gegevens vast in de database, maar die zijn uiteraard altijd aan te passen. Je kunt in de tabel met uitleenregistraties een KlantID aanpassen; simpel door de 12 te vervangen door een 13. En ja, dan heeft 'ineens' een andere klant de boeken geleend. Wij noemen dat: fraude . Want het is natuurlijk niet de bedoeling dat je registraties verandert. Gelukkig kun je dat soort zaken allemaal dicht timmeren, en ik raad je uiteraard ook aan om dat (t.z.t.) te doen. Als de db af is .

Er zat inderdaad een 'onhebbelijkheidje' in de database, omdat er geen Autonummer veld in de tabel Uitleen was, waar het subformulier wel op gekoppeld is. Dat kun je nog wel oplossen, maar ik heb er toch maar even een autonummer van gemaakt. Hierbij een nieuwe versie, op mijn db dus .

Ik heb trouwens pas net je verhaal over de betalingen gelezen; dat deel zit er dus nog niet in. Wél heb ik (want dat had ik zelf ook al bedacht) de retourprocedure aangepast, zodat je boeken per keer kan terugbrengen. Daar zit nu een knop voor in het subformulier die de datum invult. Diezelfde knop kan je ook gebruiken om de te betalen prijs te laten uitrekenen. Maar het leek mij wel nuttig als je zelf ook wat bedenkt; daar leer je namelijk meer van dan als ik alles voorkauw .