Standaardwaarde weergeven in formulier

[Riette]

Hallo,

Ik heb in mijn database twee tabellen, beide met cliëntnummer als primaire sleutel, en een op een relatie met elkaar.
Allereerst worden gegevens van de cliënt (via een formulier) ingevoerd in de eerste tabel.
Vervolgens wordt een formulier geopend, behorend bij de tweede tabel. Hierin voer je hetzelfde cliëntnummer in. Voor het vermijden van fouten, heb ik in dit formulier een veld Achternaam toegevoegd, en bij de standaarwaarde ingevoerd dat hij uit de eerste tabel de Achternaam moet zoeken.
Als ik nu een nieuw record open en een bestaand cliëntnummer invoer, komt de achternaam niet tevoorschijn. Wat doe ik verkeerd of moet ik anders instellen?

 

[OctaFish]

Ik zie de constructie nog niet helemaal voor me, maar twee tabellen met een identieke sleutel, en dus een één-op-één relatie is uiteraard altijd mogelijk.
Wat je zou moeten doen bij het openen van het tweede formulier, is de waarde van het eerste formulier 'doorgeven' aan het tweede formulier, zodat je het niet opnieuw hoeft in te typen. Want daar kun je uiteraard fouten in maken, en het is eigenlijk een overbodige actie.
Je zou zelfs kunnen overwegen om met één formulier te werken, met twee tabbladen, omdat je toch een één-op-één relatie gebruikt. Maar of dat wenselijk is kan ik uiteraard zo niet beoordelen.
Om op het tweede formulier de achternaam te zien, zou je in de bron van het tweede formulier een query moeten gebruiken die beide tabellen bevat, zodat je het veld Achternaam automatisch op je formulier te zien krijgt, als je een Klantnummer ingeeft. Het kan ook met een DLookup functie worden opgezocht, maar dat maakt bij grotere bestanden het formulier snel trager.

 

[Riette]

Ik ben er nog niet zo goed in thuis, dus vat niet meteen wat je bedoelt. Ik dacht met hetgeen in ingevuld had, dat daarmee de naam werd doorgegeven aan het tweede formulier, zodra ik het cliëntnummer intyp. Wat bedoel jij met doorgeven?

Wat voor query zou ik moeten maken om dat voor elkaar te krijgen? Die moet je dan elke keer toepassen?

 

[Tardis]

Een op eeen relaties lijken mij in jouw geval te duiden op het onjuist opzetten van je gegevensstruktuur.

Begin bij het begin en wel, verdiep je eerst eens in de principes hoe databasestrukturen op te zetten.
Google eens op

Codd

of op

normalisatie

Bekijk voorbeeldbestand (zoals de Noordenwind voorbeelddatabase).
Ga daarna aan de slag met het volgens het geleerde opzetten van jouw databasestruktuur.
Succes!

Grtz,

Tardis

 

[Riette]

Sorry hoor, als mijn vragen je irriteren. Ik dacht dat een forum ook voor beginners was.
Ik heb Noordenwind bestudeerd en het boek Access 2007 van Ko Lammers (ruim 800 pag).
Daarna ben ik naar beste weten begonnen met mijn database. Ik wil af en toe dingen die niet voorkomen in Noordenwind en niet beschreven staan in het boek. Daar is het forum toch voor?

 

[Tardis]

Irriteren?
Ik?
Waarom?

Is het wellicht zo dat jij geirriteerd bent?
Als je geen behoefte hebt aan goedbedoelde tips zeg dat dat gewoon.
Dan laat ik het er verder bij.

Grtz,

Tardis

 

[OctaFish]

Niks van die opmerking aantrekken, ik maak zelf ook wel eens één-op-één relaties, ze kunnen zelfs absoluut noodzakelijk zijn! Voorbeeldje? Je hebt een tabel Personeel, en je wilt activiteiten bijhouden waar mensen aan meedoen. Dan wil je die niet in de personeelstabel bijhouden, dus daar maak je een aparte tabel voor met een één-op-één relatie. Of, in dezelfde tabel Personeel, je wilt de gevoelige informatie afschermen van de algemene informatie.
Dus, zonder kennis van je db, het principe afschieten, is een beetje voorbarig van Tardis...

Om op je vraag terug te komen: het is helemaal afhankelijk van hoe je het tweede formulier (wilt) openen. Ik kreeg de indruk dat je het tweede formulier wilt openen met dezelfde gegevens als uit het eerste formulier. Daarvoor moet je dus iets doen, wat licht buiten de gebaande standaardpaden gaat. Maar het is wel mogelijk, met een paar extra handelingen.

Het zou overigens wel helpen, als je een voorbeeldje zou kunnen posten, uiteraard zonder gevoelige infomatie, want dan kunnen we wat gerichter helpen.

Om te beginnen, moeten we dus weten waar je eerste formulier op is gebaseerd, en waar je tweede form. Je kunt veld, in jouw voorbeeld Achternaam, pas laten zien als je op het tweede formulier het KlantID hebt ingevuld. Als je echter een tabel aan het formulier hebt gekoppeld waar dat gegeven niet in zit, dan kun je het ook niet laten zien. Je moet dan dus ingewikkelde constructies uithalen om het wèl te tonen. Maak je een query, waarbij je alle velden die je wilt zien opneemt, en als Bron voor je formulier gebruikt, dan zie je op het formulier gelijk de Achternaam in het veld, omdat je immers het KlantID ook al hebt. Zo werkt dat ongeveer met queries.

Wat ik bedoel met het doorgeven van het KlantID aan het tweede formulier is een truc, waarbij je een zgn. 'Argument' meegeeft aan het commando dat het tweede formulier opent. Vervolgens ziet het tweede formulier de waarde die bij het openen als argument is meegegeven, en dat zet je dan op het formulier als gegeven. Het klikt simpel, en het is ook niet heel erg moeilijjk, maar om het werkend te maken, is dus een voorbeeldje wel handig...

 

[Riette]

Hoe post ik een voorbeeld? De hele database als bijlage? Er staat alleen nog testinformatie in, maar is nu ca 11 MB. Eerst inpakken?

 

[OctaFish]

11 MB is al vrij stevig, zeker als je alleen testdata hebt. Je kunt, om te beginnen, kijken of de grootte terug is te brengen met <Extra>, Database hulpprogramma's>, <Database comprimeren>.
Als de grootte dan ongeveer 1 MB is, kun je de db met Winzip of Winrar wel inpakken. Hierbij moet de grootte wel kleiner zijn dan 100kb, anders moet je de Rar opsplitsen. Dat kun je doen door te comprimeren met de volgende instellingen (zie plaatje)

Mocht het bestand zo groot blijven, dat je meer dan 3 partjes overhoudt, probeer dan de tabellen te verwijderen die je niet nodig hebt voor het probleem. Je houdt dan dus in ieder geval de twee één-op-één tabellen over, en de twee formulieren.
Dan weer comprimeren, en zippen.

 

[Tardis]

@ OctaFish,

beetje flauwe reaktie.
Anyway, jij schijnt jezelf als expert te beschouwen waarbij je je een redelijk arrogante houding aan te moeten meten.
Dat ben je zeker niet als ik zo eens door je reakties heenfiets.
Jammer alleen dat je daarmee anderen dingen aanleert die ik niet zou kunnen betitelen als aanbevelenswaardig.

Wees gerust, mij zie je niet meer terug op dit forum.

Tardis

 

[OctaFish]

@Tardis:
Ik zie mezelf niet echt terug in jouw omschrijving, maar ik vind jouw reacties ook niet altijd even om over naar huis te schrijven.... Volgens mij heb jij ook een kast vol ongebruikte schoenen liggen...
En ja, ik probeer mensen te helpen, uitgaande van de bestaande situatie, en niet gelijk alles op de schop te gooien. Met zachte hand bijsturen a.h.w...

 

[Riette]

Dit gaat me vandaag niet meer lukken. Morgen weer terug

 

[OctaFish]

Prima. Als het een 2007 db is, kan ik er pas morgenavond naar kijken.

 

[hanswe]

Database structuur

Hoi,
Ik weet niet of je probleem opgelost is, maar zowel Octafish als Tardis hebben gelijk.
Tardis heeft gelijk omdat een gestructureerd database concept uiterst belangrijk is en 2 tabellen met dezelfde primary key, is vragen om problemen.
Octafish heeft gelijk omdat een moeilijk lijkend probleem niet altijd gecompliceerd hoeft opgelost te worden.
Mocht je er nog niet uit zijn neem dan contact op en hoogstwaarschijnlijk ligt de oplossing boven aan de oppervlakte.
Laat wat van je horen.
Nog 1 tip aan Tardis. Het valt mij op dat jij op alles wat aan te merken hebt maar voor geen enkel probleem een oplossing aandraagt. Heb je niets beters te doen dan iedereen af te kraken.

 

[hanswe]

2 maal dezelfde primary key

Nog 1 tip
Misschien heb je hier wat aan. Als men vanuit het hoofdinvoerscherm naar een 2de invoerscherm gaat met een relatielink dan wordt het veld van de relatie van het hoofdscherm, in jou geval de primary key, gelocked om een deadlock te voorkomen. Je neemt namelijk de data van je primary key van scherm 1 mee naar scherm 2. Zou je in scherm 2 deze key kunnen wijzigen dan weet Access niet meer waar je gebleven was in scherm 1.
Locking problemen zijn zeer lastige problemen die naar hele complexe wijzigingen vragen (roll back en roll foreward).
Sorry voor de wat warigge uitleg maar over locking zijn complete boeken geschreven en tot op heden is daar nog geen afdoende oplossing voor. Van de 195.000 bugs in Microsoft Windows heeft er meer dan de helft betrekking op locking.

 

[Riette]

OK, ik heb het blijkbaar verkeerd aangepakt. Geen probleem, er zijn nog geen data ingevuld, dus begin ik gewoon opnieuw.
Er moeten per cliënt tussen 40 en 50 gegevens worden ingevuld, die in verschillende categorieën vallen. Daarom leek het mij handig daar verschillende tabellen van te maken.
Een aantal invulvelden worden keuzes uit andere tabellen. Dat krijg ik wel voor elkaar.
Dus alles in één tabel zetten?

 

[OctaFish]

Het hangt er vanaf of je voor alle cliënten die 40 of 50 gegevens moet invullen. Als je al op voorhand weet dat je cliënten in twee soorten vallen, waarbij de ene soort ongeveer 20 gegevens ingevuld krijgt, en de andere categorie 40 à 50, dan kun je wel degelijk een constructie met een één op één relatie gebruiken. Moet alles toch wel worden ingevuld, dan zou ik het ook in één tabel houden, dat is een stuk makkelijker.
Voor je keuzelijsten kun je aparte tabellen maken, of, als het om een paar opties gaat, kun je de opties ook opslaan in de keuzelijst zelf. Voorbeeldje: voor een keuzelijst Geslacht maak ik meestal geen tabel, want heel veel smaken heb je daar niet in. De keuze-opties kun je dan al in je tabelontwerp opnemen, en die worden dan overgenomen door de keuzelijst.
Streef ernaar om het aantal tabellen zo klein mogelijk te houden, maar probeer ook om alle zelfstandige gegevensgroepen in een eigen tabel op te slaan.
Zo kun je facturen meestal opsplitsen in twee tabellen: de tabel tFactuur, en de tabel tFactuurRegels. Waarom doe je dit? Omdat een factuur uit meerdere regels kan bestaan, die eigenlijk allemaal een eigen gegevensgroep vertegenwoordigen: een besteld artikel. De factuur bevat de hoofdgegevens, die je niet op elke regel wilt herhalen, zoals de klantgegevens, factuurdatum etc.

 

[hanswe]

Faktuur voorbeeld

Even als aanvulling op het faktuurvoorbeeld hiervoor. Octafish heeft het over 2 tabellen ipv 1.
Een faktuur maken vraagt veel meer dan 2 tabellen.
a. Een artikeltabel met als primkey artikelnummer en indien nodig een aparte tabel met artikel groepen.
b. Een BTW tabel want wijzigt de BTW dan wil je (en moet je van de fiscus) kunnen zien welke bedragen hoe belast zijn.
c. Een kosten tabel zoals verzendkosten, want dit is geen omzetgegeven.
d. Een klanten tabel. 1 klant kan meerdere fakturen hebben, maar in het geval dat deze niets koopt ook geen faktuur.
e. Een faktuur tabel die alleen bestaat uit factuurnr, datum, en faktuurregel nummers.
f. Een faktuurregel tabel dat bestaat uit regel nummer, factuurnr, aantallen, artikelnr, bedrag, enzomeer
Dit zijn de minimale tabellen maar dat is nog uit te breiden met andere tabellen die speciaal voor jou van belang zijn. Ik neem aan dat he nog iets wil met de data gezien je 50 velden wilt vullen.
Alle andere bewerkingen zoals faktuur maken, btw aangiftes, omzetbepaling, winstberekening, enz doe je met behulp van Forms, Rapporten, Query > Forms, Query > Rapporten en voor de wat gevorderde gebruiker dmv Visual Basic programma's.
Het klinkt moeilijk maar gewone Forms, Query em Rapporten zit bij elke Access (vanaf Access 1997) een wizzard die je door het proces heen kan helpen.
Voor moeilijke processen heb je nog een andere wizzard, genaamd Octafish die mij ook door lastige problemen heen geholpen heeft (bedankt Octafish) ondanks dat ik al meer dan 30 jaar systeem ontwerper ben geweest en ik toch meer weet dan de doorsnee.

 

[Riette]

De 40-50 gegevens moeten voor elke cliënt worden ingevuld. Ik had begrepen dat je niet het aantal tabellen moest beperken, maar juist het aantal velden per tabel.

Al jullie voorbeelden gaan over standaard bedrijven (zoals ook Noordenwind), maar ik moet hele andere dingen hebben. Dat voert misschien erg ver in dit forum. Waar het vooral om gaat, dat ik een formulier kan maken, waar al bekende gegevens van de cliënt in zichtbaar zijn, gekoppeld aan zijn cliëntnummer, zoals zijn achternaam, bepaalde uiterste datums e.d., maar dat vervolgens in dat formulier nieuwe informatie kan worden ingevoerd, zoals korte notities van gesprekken. Net zoiets als een huisarts doet bij een consult. Hoe krijg ik het voor elkaar dat het systeem in een dergelijk formulier, zodra ik het cliëntnummer invoer, bepaalde velden automatisch invult?

Hanswe, ik beantwoord je privébericht, zodra het systeem mijn donatie verwerkt heeft, zodat ik toestemming heb voor privéberichten.

 

[OctaFish]

We gebruiken vaak standaard bedrijven (voor zover die bestaan natuurlijk...) als voorbeeld, omdat iedereen dan wel snapt wat je bedoelt. Hele specifieke databases zijn gewoon minder duidelijk voor algemeen gebruik.
Neemt niet weg, dat de basisprincipes op de meeste databases wel van toepassing zijn.
Ook in jouw geval gaat het om (een aantal) tabellen, die gegevens bevatten, die je wilt kunnen toevoegen/muteren etc.
Als je één tabel hebt met cliëntgegevens, dan kom je waarschijnlijk uit op een formulier met tabbladen, zodat je de gegevens kunt groeperen en bij elkaar kunt houden.
Als je het formulier baseert op de tabel Cliënten, kun je altijd gegevens wijzigen en toevoegen. Eventueel kun je andere tabellen koppelen aan de gegevensbron van het formulier, zodat je ook andere gegegens kunt tonen op het formulier.
Berekeneningen kun je er ook op maken, mocht dat nodig zijn.