Opgelost Ruimtebesparing bij formulier

[Jacobusje]

Goedemorgen,

Deze week ben ik begonnen met het bouwen van een database voor keuringen van machines.
Omdat dit hoogstwaarschijnlijk op een laptop gaat gebeuren en er best veel vakjes op de formulieren komen zat ik te denken....

Als ik bij de in te voeren vakjes het bijschrift weg laat maar dat in het invoervakje in lichtgrijs zichtbaar is wat daar moet worden ingevuld, zolang er niets is ingevoerd natuurlijk.
Net zoals je ziet bij je mobiel (zie bijlage)
Dat scheelt ongeveer 1-derde tot de helft aan ruimte op het formulier.

Is zoiets mogelijk?
En zo ja, hoe zou ik dat moeten doen?

 

[OctaFish]

Onzalig plan, lijkt mij, want dan moet je van alles gaan programmeren. Niet dat dat niet kan, maar of het handig is? Als je écht zoveel informatie moet invullen op één formulier (is je tabel(len) dan wel voldoende genormaliseerd, vraag ik me dan gelijk af) kun je de informatie het best groeperen op tabbladen. Want er zal ongetwijfeld een structuur in je data zitten. Dus als je 250 velden hebt (zit je ook zo'n beetje aan het maximum) dan maak je een tabblad element met 5 tabbladen voor 50 velden. Of 10 voor 25. Doen we niet moeilijk over .

 

[Jacobusje]

Naast dat het ruimte bespaart staat het ook wel chique

De controle-tabel bestaat uit ca. 50 ja/nee velden + 50 tekstvelden.
Dit zijn alle controlepunten van alle machines. (misschien komen er nog een paar bij)

Met een query wil ik daar per type machine de juiste controlepunten uit halen.
In het controle-formulier zullen dan ca 20 vinkjes komen en evenzoveel tekstvelden.
Scheiden met tabbladen lukt me wel, maar ik had gehoopt dat er met een functie / vinkje iets kan waar ik niet van op de hoogte ben.

Eigenlijk raar dat Bill Gates daar nooit over na heeft gedacht.

Mocht iemand een idee hebben, ik houdt me aanbevolen.

 

[OctaFish]

... maar dat in het invoervakje in lichtgrijs zichtbaar is wat daar moet worden ingevuld, zolang er niets is ingevoerd natuurlijk.

Nog even over dit zinnetje, want dat blijft toch ook nog hangen: hoe had je je dat voorgesteld? Velden zijn immers gekoppeld aan een tabelveld, en bevatten dus ofwel niks, ofwel een ingevoerde waarde. Géén labeltekst dus.

Een mogelijke optie zou kunnen zijn om voor alle velden die je op die manier wilt laten invullen een standaardwaarde in te vullen in de tabel, en bij het aanmaken van een nieuw record de kleur van de velden in te stellen, en voor elk veld dat je invult de kleur van het veld weer terug te zetten. Dat zou kunnen werken`met Voorwaardelijke Opmaak. Wel een berg werk, en niet geheel zonder gevaar, want deze techniek werkt alleen bij tekstvelden. Immers: als je een getal in moet vullen, dan mag je geen tekst nvullen in dat veld. Idem bij selectievakjes, al speelt daar het probleem denk ik niet, omdat je daar het label zal blijven gebruiken.
E.e.a. kun je, naast VO, ook met VBA doen. Heeft als voordeel dat je wat generiekere code kan maken, die de eigenschap DefaultValue van een veld kan gebruiken voor de vergelijking met nieuwe invoer.

Een andere manier, die het probleem van tabelvelden omzeilt, is om een niet-gebonden formulier te gebruiken dat je pas na het invoerenmet naar een tabel kopieert. Dus je voert éérst de gegevens in, en met de knop <Opslaan> leg je verbinding met de tabel en schrijf je de gegevens weg. Dan ontloop je het numerieke probleem. Maar nogmaals: de oplossing met tabbladen is een stuk makkelijker te maken .

 

[OctaFish]

Met een query wil ik daar per type machine de juiste controlepunten uit halen. In het controle-formulier zullen dan ca 20 vinkjes komen en evenzoveel tekstvelden. Scheiden met tabbladen lukt me wel, maar ik had gehoopt dat er met een functie / vinkje iets kan waar ik niet van op de hoogte ben.

Ik heb geen flauw idee wat je hiermee bedoelt. Eén formulier maken met alle 100 velden erop terwijl je er maar 40 gebruikt, lijkt mij sowieso een database probleem (normaliseren dus).

 

[Jacobusje]

Ik heb geen flauw idee wat je hiermee bedoelt. Eén formulier maken met alle 100 velden erop terwijl je er maar 40 gebruikt, lijkt mij sowieso een database probleem (normaliseren dus).

Dat heeft als reden dat er 15 verschillende machines zijn die verschillen soorten controles ondergaan.
Een deel is wel hetzelfde en een deel is afwijkend.

Het andere bericht ga ik morgen lezen, ik moet nu naar een afspraak.

 

[OctaFish]

Als je toch aan het lezen bent: maak profielen voor de verschillende types machines waarin je aangeeft welke controles er moeten worden uitgevoerd. En een tabel met Controles, waarin alle controles staan. Je hebt dan een tabel met de machines, waar je met een extra veld het profiel aan hangt. In de tabel profielen werk je met een gekoppelde tabel Profiel_Controle waarin je voor elk profiel de controles vastlegt. Dus in de tabel Profielen heb je zo'n 15 records, en in de tabel Controles misschien een stuk of 100. En de tabel Profiel_Controles bevat dan maximaal 1500 records, als elk profiel alle controles bevat. Maar dat is dus niet zo .

Hoe krijg je e.e.a. dan netjes op een formulier? Daarvoor heb ik in de cursus Access een mooie aanzet gegeven: het dynamische formulier. Dat is een formulier waarin je een aantal vaste tekstvelden/selectievelden neerzet (gebaseerd op je profielen zou ik zeggen: het maximale aantal +5, zodat je nog enige ruimte hebt voor uitbreiding later). Dat formulier moet uiteraard gekoppeld worden aan de juiste velden per machine, en dat doe je dus door bij het laden van de machine op het formulier éérst het profiel in te lezen met de noodzakelijke veldnamen, en die dan koppelen aan de gewenste velden. Alle objecten zijn dus in eerste instantie onzichtbaar, en worden zichtbaar gemaakt zodra er een veld is gekoppeld. Klinkt ingewikkeld, maar je zult zien dat het goed te doen is, als je het voorwerk correct hebt ingericht!

En anders helpen we je natuurlijk graag op basis van een voorbeeldbestandje .

 

[NoellaG]

Het meest eenvoudige is inderdaad alleen de kontroles te tonen die voor een bepaalde machine moeten gebeuren. Dat kan zonder enige programmatie als je een structuur hebt zoals:
* een tabel met de machine gegevens (ID, code, naam, ...)
* een tabel met de verschillende kontroles (ID, type, omschrijving, ...)
* een koppeltabel waarin je aangeeft welke controles voor welke machines moeten uitgevoerd worden (ID, machineID, KontroleID)
* een tabel met de effectief uitgevoerde kontroles (ID, ID uit de koppeltabel, datum kontrole, resultaat (goed/niet-goed), omschrijving kontrole, ...)

 

[xps351]

Ik weet niet hoe je gedacht had het formulier (of eigenlijk:je database) op te zetten, maar als je het hebt over meerdere controles met per controle een ja/nee veld en een tekstveld, dan denk ik al snel aan een doorlopend formulier. Dan heb je feitelijk ook geen probleem met de labels, want die staan eenmalig boven de kolommen. Maar dat lukt alleen als je je tabellen goed hebt opgezet en daar twijfel ik gezien je vraag net als OctaFish ook aan.

 

[OctaFish]

... maar als je het hebt over meerdere controles met per controle een ja/nee veld en een tekstveld, dan denk ik al snel aan een doodlopend formulier.

Ik vind dit meer een doodlopend antwoord .

 

[OctaFish]

Dat kan zonder enige programmatie als je een structuur hebt zoals:

Fijn dat je mijn complete​ antwoord nog een keer oplepelt .

 

[xps351]

Ik vind dit meer een doodlopend antwoord .

Dat heb je met die handige meedenkende toetsenborden . Is gecorrigeerd.

 

[Jacobusje]

Een mogelijke optie zou kunnen zijn om voor alle velden die je op die manier wilt laten invullen een standaardwaarde in te vullen in de tabel, en bij het aanmaken van een nieuw record de kleur van de velden in te stellen

Hier had ik ook aan gedacht, maar dan staat er ook altijd een waarde in, dat is weer niet handig met de rapporten.

Als je toch aan het lezen bent: maak profielen voor de verschillende types machines waarin je aangeeft welke controles er moeten worden uitgevoerd. En een tabel met Controles, waarin alle controles staan. Je hebt dan een tabel met de machines, waar je met een extra veld het profiel aan hangt. In de tabel profielen.......

Dit klinkt voor mij nogal ingewikkeld, komt dit op hetzelfde neer wat ik voor ogen had met de querys? Voor elk type machine een query? het controle-formulier is dan gebaseerd op de betreffende query. (Dus eigenlijk is mijn query de koppeltabel)

Ik weet niet hoe je gedacht had het formulier (of eigenlijk:je database) op te zetten, maar als je het hebt over meerdere controles met per controle een ja/nee veld en een tekstveld, dan denk ik al snel aan een door(d)lopend formulier.....

Dat lijkt mij een goed idee, misschien heb ik dat wel eens ergens gebruikt, dat moet ik opzoeken....

Bijgaand het voorbeeld, was net begonnen met de query (koppeltabel ) voor de boormachines.

 

[xps351]

Zoals in diverse reacties al vermoed werd is het ontwerp van je tabellen niet deugdelijk. Door voor elk soort controle velden op te nemen overtreedt je al een belangrijke basisregel: in velden sla je waardes op. Jij slaat waardes (soort controle) op in veldnamen.
Een gevolg hiervan is onder andere dat als er iets verandert (er komt bijvoorbeeld een soort controle bij) je het ontwerp van je database aan moet passen. Dat kan niet de bedoeling zijn. Een gebruiker zou dat via een formulier moeten kunnen regelen. Ook is het in deze opzet erg lastig consistent vast te leggen welke soorten controles vereist zijn bij een bepaalde machinegroep.
Dat je voor elke machinegroep een query zou moeten opzetten om vast te leggen welke controles voor een machinegroep uitgevoerd zouden moeten worden gaat ook niet echt werken. Ook dit betekent aanpassingen in databasecomponenten (query's) die je niet aan een gebruiker kunt overlaten in het geval van verandering (nieuw machinegroep, verandering van de vereiste controles). Nog los van het feit dat ik eigenlijk geen idee heb wat je met die query('s) wil.

Je hebt dus niet zozeer een ruimteprobleem, maar een (groot) ontwerpprobleem.

In navolging van mijn voorgangers heb even een model in elkaar geknutseld dat mijns inziens beter voldoet.
Dat model representeert enerzijds welke controles per machinegroep vereist zijn (tblVereisteControle). Aan de andere kant staan de daadwerkelijk uit te voeren c.q. uitgevoerde controles (tblKeuring en tblKeuringDetail).
In dit model ben je flexibel en kan de gebruiker zelf controlesoorten en vereiste controles toevoegen zonder dat het ontwerp aangepast hoeft te worden. Je kan het relatief eenvoudig zo maken dat zodra een keuring wordt toegevoegd, de keuringdetails op basis van machinegroep van de betrokken machine en de op dat moment vereiste controles, automatisch worden aangemaakt.
Als je nu een ruimteprobleem hebt is dat in de hoogte van het door(d)lopende formulier (subformulier met keuringdetails), maar daar kan je gewoon in scrollen.

 

[OctaFish]

Hier had ik ook aan gedacht, maar dan staat er ook altijd een waarde in, dat is weer niet handig met de rapporten.

Dat klopt sowieso niet wat je hier schrijft: rapporten zijn gebaseerd op ingevulde records. Standaardwaardes zie je alleen bij een nieuw record, dus nooit in een rapport.

Dus eigenlijk is mijn query de koppeltabel)

Dat is onzin; een query kan nooit een (koppel)tabel zijn. Een query is altijd gebaseerd op (een) tabel(len).

Ik zal eens naar je voorbeeld kijken, maar ik vermoed dat Peter er niet ver naast zit met zijn opmerkingen.

 

[Jacobusje]

Goedemorgen,

Bedankt voor jullie reacties!

Dat klopt sowieso niet wat je hier schrijft: rapporten zijn gebaseerd op ingevulde records. Standaardwaardes zie je alleen bij een nieuw record, dus nooit in een rapport.

Dat wist ik niet, goed om te weten.

Dat is onzin; een query kan nooit een (koppel)tabel zijn. Een query is altijd gebaseerd op (een) tabel(len).

Weer wat geleerd, ik dacht dat zo ook kon

@Peter,
Jouw uitleg ga ik als leidraad gebruiken voor de verdere ontwikkeling.
Omdat ik hiermee niet de hele dag bezig kan zijn hoop ik lopende deze week even te reageren of het is gelukt en anders aanvullende vragen te stellen

 

[Jacobusje]

Dit lijkt super te gaan, bedankt!

De tabellen en relaties heb ik bijna letterlijk overgenomen, al kan ik nog niet zeggen dat ik het helemaal door heb.
De relaties gingen ook gelijk goed, dat is bij mij nog wel eens anders.

Het "vullen" van een nieuwe keuring is nu nog een dingetje.

Je kan het relatief eenvoudig zo maken dat zodra een keuring wordt toegevoegd, de keuringdetails op basis van machinegroep van de betrokken machine en de op dat moment vereiste controles, automatisch worden aangemaakt.

Naar mijn idee werkt de database pas als dit is gemaakt. Ik denk met code.... Maar hoe?

Vanuit de machine wil ik een nieuw keuring aanmaken, dan moet het een leeg record zijn met wel het machine ID van waaruit wordt gewerkt.
Daarvoor had ik onder een knop de code (uit een ander database) samengesteld.

Private Sub Knop43_Click()

    Me.Refresh

    Dim stDocName As String
    Dim stLinkCriteria As String
    Dim stIDmachine As String
            
    stDocName = "FRM_Keuring_Invoer"
    stIDmachine = Me.ID_Machine
    
    stLinkCriteria = "[ID_Keuring]=" & Me![ID_Machine]
    DoCmd.OpenForm stDocName, , , stLinkCriteria
    
    Forms!FRM_Keuring_Invoer.ID_Machine = stIDmachine
    Forms!FRM_Keuring_Invoer.ID_Machine.DefaultValue = "= " & stIDmachine & ""

End Sub

Maar die opent wel het invoerformulier, echter niet met een nieuwe keuring maar met de bestaande keuring.

Bij deze code moet dan ook het deel komen om de betreffende keuringseisen toe te voegen, daarmee weet ik niet hoe te beginnen.
Kan iemand mij helpen om dit verder op te zetten.

 

[xps351]

Ik had al wat zitten knutselen (just for fun) om mijn stelling dat je relatief eenvoudig automatisch keuringdetails kan genereren ook echt waar te kunnen maken. Mijn opzet is iets anders. Ik open het keuringsformulier en voeg daar een keuring toe. De machine kies ik via een combobox. Zodra die gekozen is wordt een code afgetrapt die de details toevoegt op basis van de soort machine.

De code heb ik niet paraat omdat ik nu op een tablet werk. Vanavond kom ik erop terug.

 

[OctaFish]

Aan een plaatje hebben we niks, aan de database des te meer . Je kunt prima vanuit de machine een keuring aanmaken, zou ik zelf vermoed ik ook doen. Dus: database comprimeren en herstellen, zippen en posten .

 

[xps351]

Bij deze code moet dan ook het deel komen om de betreffende keuringseisen toe te voegen, daarmee weet ik niet hoe te beginnen.

Omdat ik gekozen had voor een iets andere opzet, wordt de code om keuringdetails te generen op een wat andere manier gestart dan jij zou moeten doen. De kern blijft echter hetzelfde.
Zoals ik al schreef heb ik om een en ander uit te proberen een keuringformulier gemaakt met een combobox om de machine te kiezen. Zodra je een machine hebt gekozen wordt met behulp van de gebeurtenis "na bijwerken" de code gestart. Die ziet er zo uit:

Private Sub MachineID_AfterUpdate()
    Dim M_soort As Long

    DoCmd.RunSQL "DELETE * FROM tblKeuringdetail WHERE KeuringID = " & Me.KeuringID
    Me.Refresh
    
    M_soort = DLookup("MachinesoortID", "tblMachine", "MachineID = " & Me.MachineID)
            
    DoCmd.RunSQL "INSERT INTO tblKeuringdetail (KeuringID, ControlesoortID) " & _
        "SELECT " & Me.KeuringID & ", tblControlesoort.ControlesoortID " & _
        "FROM tblControlesoort INNER JOIN tblVereisteControle " & _
        "ON tblControlesoort.ControlesoortID = tblVereisteControle.ControlesoortID " & _
        "WHERE tblVereisteControle.MachinesoortID = " & M_soort

    Me.frmKeuringDetailSub.Requery
End Sub

Toelichting:

• In mijn opzet kan in beginsel de machine van een keuring nog wijzigen (als je je vergist hebt). Vandaar dat eerst de bestaande keuringdetails bij de keuring verwijderd worden.
• Vervolgens zoek ik de machinesoort van machine op (ik heb de vereiste controles omgehangen van machinegroep naar machinesoort omdat me dat gezien de waardes logischer leek).
• De kern van de code is het INSERT statement dat alle vereiste controles van de machinesoort bij elkaar zoekt en voor elk controle een record in de tabel keuringdetails zet.

Voor de volledigheid voeg ik mijn keuringformulier en aangepaste datamodel toe.