Formulier in Access (2016)

Status
Niet open voor verdere reacties.

AoKuang77

Nieuwe gebruiker
Lid geworden
12 okt 2018
Berichten
4
Goedemorgen,

Ik heb in Access 2016 een formulier gemaakt, die put uit meerdere tabellen. Echter, wanneer ik het formulier op de "form view" zet, zie ik geen enkele van mijn velden; alleen de afbeelding.

Weet iemand hoe dit mogelijk is? Ik heb de eigenschappen al vergeleken met die van een ander formulier, maar ik zie geen verschil.

Ik ben benieuwd of iemand dit probleem kan (helpen) oplossen.
 
Uw "bron" van uw formulier kan oa een query zijn van die verschillende tabellen? Als je die niet open krijgt of deze bevat geen gegevens dan zal uw formulier leeg zijn (tenzij je natuurlijk bij het laden van het formulier al een filter toepast op een of ander manier). Is eigenlijk beetje gissen tot je een voorbeeld probeert te zetten dat we kunnen bekijken.
 
Hartelijk dank voor de reactie.

De bron van mijn formulier zijn meerdere tabellen. Ik heb ook een formulier, waarbij de bron één tabel is en daar zie ik in het formulier wel alle invoervelden. In het andere formulier dus niet.MSACCESS_2018-10-12_10-07-52.png
 
Als dit plaatje het database ontwerp weergeeft, trek ik de conclusie dat het een vreemd ontwerp is.

Ik trek de conclusie dat de wens is:

Er wordt een project uitgevoerd waarvoor wekelijks de werkzaamheden, het materiaal verbruik en de uren per medewerker vastgelegd worden.
Ik kom uit op dit ontwerp.
DBrelaties.PNG

Voor de artikelen en medewerkers komen er twee aparte aparte queries:
Voor artikel:
QueryArtikel.PNG
Met als resultaat:
ArtikelOut.PNG

Voor de medewerkers een vergelijkbare query.

Ik hoop dat dit helpt.
 
Ik vind het ontwerp van Wout wel beter dan dat van TS, want dat ziet er inderdaad uit als een heel slecht genormaliseerde database (makkelijkste manier om dat te zien: herhalende identieke velden met identieke veldnaam met volgnummer; dat zou in een normale database niet voor mogen komen). Maar ook het ontwerp van Waut zou ik zelf zo nooit bouwen. Zonder te weten wat precies de bedoeling is van de db, is het overigens gissen naar hoe het ontwerp er wél uit zou moeten zien. Voorlopige conclusie: stoppen met je huidige opzet, en eerst terug naar de tekentafel.

Sowieso moet je pas naar formulieren gaan kijken als het tabel ontwerp af is, en goed werkt. En ‘goed werken’ is dan: je kunt in alle tabellen en queries de juiste gegevens zien en invoeren, en de juiste informatie opvragen. Want een goed database ontwerp is nietzozeer bedoeld om van alles in een tabel te stoppen (dat kan met jouw ontwerp immers ook) maar om de juiste informatie er weer uit te halen :).

Normaal gesproken zou ik zeggen: post een voorbeeldje van je database. Dat lijkt me in dit geval dus wel handig voor ons om te controleren of we gelijk hebben, maar ik zou liever zien dat je eerst je database normaliseert met de juiste tabellen, en dat voorbeeld dan post. Als de vraag/probleem nog bestaat natuurlijk :). (Denk eigenlijk van niet, want ik denk dat je probleem ook wordt veroorzaakt door de verkeerde structuur)
 
Ik vind het ontwerp van Wout wel beter dan dat van TS, want dat ziet er inderdaad uit als een heel slecht genormaliseerde database (makkelijkste manier om dat te zien: herhalende identieke velden met identieke veldnaam met volgnummer; dat zou in een normale database niet voor mogen komen). Maar ook het ontwerp van Waut zou ik zelf zo nooit bouwen. Zonder te weten wat precies de bedoeling is van de db, is het overigens gissen naar hoe het ontwerp er wél uit zou moeten zien. Voorlopige conclusie: stoppen met je huidige opzet, en eerst terug naar de tekentafel.

Sowieso moet je pas naar formulieren gaan kijken als het tabel ontwerp af is, en goed werkt. En ‘goed werken’ is dan: je kunt in alle tabellen en queries de juiste gegevens zien en invoeren, en de juiste informatie opvragen. Want een goed database ontwerp is nietzozeer bedoeld om van alles in een tabel te stoppen (dat kan met jouw ontwerp immers ook) maar om de juiste informatie er weer uit te halen :).

Normaal gesproken zou ik zeggen: post een voorbeeldje van je database. Dat lijkt me in dit geval dus wel handig voor ons om te controleren of we gelijk hebben, maar ik zou liever zien dat je eerst je database normaliseert met de juiste tabellen, en dat voorbeeld dan post. Als de vraag/probleem nog bestaat natuurlijk :). (Denk eigenlijk van niet, want ik denk dat je probleem ook wordt veroorzaakt door de verkeerde structuur)

Ik snap je opmerking, maar de opzet van de database heb ik zo gemaakt vanwege het formulier. Ik had namelijk in de eerste tabel alles gezet, met als gevolg dat in het formulier ik, als ik iets invulde, dit terugzag in alle velden; het werd dus gewoon overgenomen. Wat ik wil is een database, waarin ik kan bijhouden wie welke extra werkzaamheden heeft uitgevoerd op een project. Daarbij komt, dat er dan ook bij moet komen te staan, wat er aan extra materiaal gebruikt is en wat de inkoopprijs ervan is. In bijgevoegde afbeelding is te zien hoe ik het in eerste instantie had op het formulier. Dit werkte in principe wel, maar wanneer ik een aantal invulde kwam dit aantal in alle vakken eronder ook terug.

MSACCESS_2018-10-15_05-53-43.png
 
Voor de volledigheid; nu laten we mensen zaken op papier invullen (zie afbeelding). Dit kost teveel uitzoekwerk, waardoor ik op het idee kwam om e.e.a. in Access te zetten. Alleen is het gebruik van Access alweer even geleden...:confused:

Capture.PNG
 
Twee dingen: elke nieuwe Helpmij gebruiker moet er blijkbaar een keer doorheen: de QUOTE knop is precies dat: een knop om quootjes uit een ander bericht te halen. Het is geen antwoordknop. Daarvoor heb je de veel grotere knop <Regeer op bericht> (wat moeten de moderators eigenlijk als tekst op de knop zetten voordat gebruikers snappen waar hij voor is?) en het belachelijk veel grotere tekstveld <Snel reageren>. Leer je muis dus om niet naar de rechteronderhoek te schuiven als je een antwoord wilt geven op een bericht. Je snapt het: ervaren gebruikers gruwen van dat nodeloze geklik op de Quote knop :D.

Ik snap je opmerking, maar de opzet van de database heb ik zo gemaakt vanwege het formulier.
Tweede punt gaat over de bovenstaande zin. Formulieren vormen de laatste stap van het database ontwerp, nooit de eerste. En je maakt dus nooit een database omdat je een bepaald formulier zo mooi vindt. Het gaat in de eerste, tweede en derde plaats in een db om het zo optimaal mogelijk opslaan en terughalen van gegevens. Formulieren zijn daar, net als rapporten, een hulpmiddel bij. Nooit een doel.

Op basis van plaatjes kunnen we nog steeds niks zinnigs zeggen, daar hebben we echt een (geanonimiseerde) database voor nodig.
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan