Opgelost Ruimtebesparing bij formulier

Dit topic is als opgelost gemarkeerd
Status
Niet open voor verdere reacties.
Helaas ben ik er vandaag niet aan toe gekomen, morgen weer een kans.

Bijgaand vast het voorbeeld van wat ik in elkaar heb gezet.
 

Bijlagen

  • Machinekeuringen__.zip
    135 KB · Weergaven: 6
Een beetje moeilijke (zo niet onwerkbare) gebruikersinterface. Via het navigatieformulier kan ik alleen een machine toevoegen, maar niet meer terugvinden. Ook verwarrend: keuringen kan je op twee manieren toevoegen (via het subformulier bij machine en via de knop op dat formulier). Ook keuringen kan je toevoegen, maar niet meer terugvinden.

Ik heb wat kleine aanpassingen gedaan. Via het formulier machines kan je nu machines bekijken, wijzigen en toevoegen. Via het subformulier voeg je een keuring toe (de details worden automatische aangemaakt). Met de knop op het subformulier ga je naar de keuring en kan je de details bewerken.

Veel plezier ermee :thumb:
 

Bijlagen

  • Machinekeuringen_PS.zip
    138,6 KB · Weergaven: 9
Laatst bewerkt:
Goedemiddag,

Dat ziet er goed uit Peter.
Daar kan ik wel mee verder.

Maar jou opmerking over mijn onwerkbare navigatie zit me wel dwars :(

Via het navigatieformulier kan ik alleen een machine toevoegen, maar niet meer terugvinden.
Dat terugvinden moet ik er nog inbouwen, zo ver was ik nog niet, geldt ook voor rapporten.

Ook verwarrend: keuringen kan je op twee manieren toevoegen (via het subformulier bij machine en via de knop op dat formulier)
In het subformulier zat een dubbeklikfunctie die de betreffende keuring opende, jij hebt dat onder de knop "Bewerk" zitten, de keuring was wel degelijk terug te vinden.
De knop die op het formulier stond had ik bedoeld om een nieuwe keuring aan te maken bij die machine die open staat, en dan gelijk de items laden in het lege keuringsformulier, die jij laad bij het kiezen van een keurmeester. Maar die code wist ik niet. Deze leek hetzelfde te doen.

Nogmaals allemaal bedankt voor het meedenken.
 
Ik zou zowel jouw oplossing, als die van Peter naar de prullenbak brengen, er een stevige neut op nemen en het oorspronkelijke ontwerp nog eens goed tegen het licht houden, want eerlijk gezegd klopt er niet zoveel van. Zo heb je een tabel TBL_Controlesoort, die in mijn ogen informatie bevat die thuishoort in de tabel TBL_Controles. Immers: controlesoort zegt iets over de controles. Nope, in de tabel tbl_Controles géén veld ControlesoortID. Wél is die tabel volkomen niet-genormaliseerd, doordat er véél te veel velden in staan. Je zou kunnen volstaan met een extra tabel met deze velden:

Code:
ControleDetails_ID
Controle_ID
ControleSoort_ID
Opmerking

Je hebt dus een tabel met Controlegegevens, ControleSoort en ControleDetails. Je maakt dan voor élke controle in de tabel ControleDetails precies zoveel records als je nodig hebt voor een controle. Nu heb je een tabel Controles met meer dan 50 velden (ik ben gestopt met tellen) die je vast niet allemaal nodig hebt bij een controle. Leg dus alleen die controlesoorten vast die je nodig hebt voor een specifieke controle!

Dán heb je een netjes genormaliseerde tabel, die nog eeuwen meekan. Nu is het toch een beetje (excusez les mots) broddelwerk. Laat ik het zo zeggen: als je mij de db laat maken, ziet hij er heel anders uit :).
 
Ik zou zowel jouw oplossing, als die van Peter naar de prullenbak brengen ....
Nu heb je een tabel Controles met meer dan 50 velden (ik ben gestopt met tellen)
Als je het draadje een beetje gevolgd had, zou je begrepen hebben dat die (terecht) gewraakte tabel een overblijfsel is uit het oorspronkelijke ontwerp dat inderdaad goed tegen het licht is gehouden. In het uiteindelijke model speelt die geen rol. Het enige dat dus naar de prullenbak hoeft is die tabel en post 25#.
 
Ik zie in de nieuwe database een situatie die ik niet in een database zou willen. Maar ga gerust je gang om daar wat van te maken :). That's all....
 
Goedemorgen,

Een borrel op z'n tijd is niet verkeerd, maar om alles in de prullenbak te gooien...
De tabel controles is ondertussen verwijderd. Die informatie heb ik in de nieuwe tabellen overgezet, scheelde me een hoop typewerk.
Dat Peter en OctaFish het verschillend zien is iets waar ik niet bij kan met mijn pet.

Het aanmaken / vullen met de vereiste controles vindt ik niet lekker lopen.
Je kiest een keurmeester en vervolgens worden de vereiste controles aangemaakt.
Bij openen van het keuring formulier is de keurmeester niet ingevuld.

Nu heb ik de knop, die was verwijderd, weer toegevoegd .
Daar heb ik de code ingeplakt uit het subformulier.
Maar nu heeft hij dus nog geen ID-keuring en loopt vast. (dat had ik wel verwacht.)

In mijn beleving zou het volgende moeten gebeuren bij het klikken op de knop "Nieuwe keuring aanmaken":
- Openen van keuringsformulier met het machine ID van de huidige machine in het hoofdformulier
- Er word dan een nieuwe ID_keuring aangemaakt
- Daarin worden de vereiste controles, die aan de machinesoort hangen, geladen
Vervolgens kiest de keurmeester zijn naam en vult de datum in.

De code die gebruikt is kan ik niet doorgronden, hoe die dan zou moeten worden kom ik ook niet uit.
Zie iemand nogmaals kunnen helpen?
 

Bijlagen

  • Machinekeuringen_231006.zip
    100,7 KB · Weergaven: 8
Dat Peter en OctaFish het verschillend zien is iets waar ik niet bij kan met mijn pet.
Niks van aantrekken, dat is standaard zo :D


Je kiest een keurmeester en vervolgens worden de vereiste controles aangemaakt.
Bij openen van het keuring formulier is de keurmeester niet ingevuld.
De controles worden aangemaakt in de gebeurtenis "voor invoegen". Dus ook als je bijvoorbeeld een datum zou invullen gaat die gebeurtenis af en worden de controles aangemaakt.
Dat de keurmeester niet wordt getoond (het gegeven is er wel) komt doordat de instellingen van de betreffende combobox op jouw formulier niet juist zijn. Ik heb dat over het hoofd gezien en inmiddels in mijn versie gecorrigeerd.


Nu heb ik de knop, die was verwijderd, weer toegevoegd.
Dat is jouw keuze en moet je zeker ook zo maken. Ik heb alleen voorstel gedaan hoe het ook zou kunnen.
Ik heb eerder uitgelegd waarom ik die knop overbodig vindt. Zoals je ziet in mijn voorstel is die ook niet nodig omdat alles "gewoon" werkt (na een kleine aanpassing ook inclusief het tonen van de keurmeester). Als je de knop toevoegt en de code bij de gebeurtenis "voor invoegen" weghaalt, zou de gebruiker via het subformulier een keuring aan kunnen maken zonder dat er controles worden toegevoegd. Dat moet je dus nog even zien te voorkomen.

Ik zal nog even kijken of ik jouw code werkend krijgt.
 
Laatst bewerkt:
Niks van aantrekken, dat is standaard zo :D
Daarom moet je altijd zelf bepalen hoe jouw Functioneel Ontwerp er uit ziet, wat de database moet doen, wat je er uit wilt halen etc. Wij zijn (ik althans niet) nog geen dag door jou geconsulteerd, hebben dus ook geen enkel benul van wat jij nodig hebt en wat daar voor nodig is, en kunnen dus alleen op basis van de door jou nu aangegeven informatie proberen er wat chocola van te maken. Hooguit kunnen we je wat algemene tips geven.

Wat je (in beginsel) dus nooit moet doen: voorbeelden van ons klakkeloos overnemen en daar verder mee gaan werken. Want alleen jíj weet wat je nodig hebt, en wat je voor ogen hebt. Normaal gesproken, bij een bedrijf, huur je dan ook een consulent in die de huidige situatie bekijkt en op basis daarvan, en jouw wensen uiteraard, voorstellen doet. Zeker als je zelf te weinig (database)kennis (in huis) hebt, is advies vragen een goede zaak. HelpMij als forum is daar uiteraard totaal ongeschikt voor, omdat niemand hier jouw situatie kent.
 
De situatie is zo.

We zijn een kleine fabriek die voor de bouw houten elementen maakt.
Een van de personeelsleden heeft op zich genomen om de kleine machines te keuren.
We zijn dat in juli opgestart met standaard formulieren in Excel, maar het is een ramp om dat in te vullen en te bewaren.
3 weken terug zei ik "dat kan veel mooier in acces", omdat ik wel meer dingen in acces heb gemaakt.... (een beetje kennis heb ik wel, het normaliseren lijkt dus niet genoeg ontwikkeld)

We hebben niet veel nodig, alleen machines met onderliggende keuringen waar we wat vinkjes willen zetten.

Maar met de vraag over ruimtebesparing liep het even uit de hand, dat dit zo totaal anders moest / ingewikkelder was had ik niet voorzien. :eek:
 
Hele herkenbare situatie. Dat begint vermoedelijk al met een verkeerd opgezet Excel bestand waar ze in het Excel forum graag de tanden in zouden zetten :). Want vermoedelijk zouden jullie met een goed bestand best een tijdje vooruit kunnen. met een slecht werkend Excel bestand ga je natuurlijk naar een ander pakket kijken, maar eigenlijk ga je dáár al de fout in!

Bij het zoeken naar een automatiseringstraject ga je kijken naar de vraag (we willen machines keuren), naar de processen (nu op papier, maar liever digitaal om maar wat te noemen), en dan gaat een informatie analist kijken hoe je dat het beste kunt vormgeven. Op basis van een Functioneel Ontwerp komt er dan een digitale workflow uitrollen, en dat wordt dan in een applicatie uitgewerkt. Dat kan dus bij jullie prima in Excel worden gemaakt, als een analist dat voor jullie het beste vind, of in Access.

Wat je eigenlijk niet moet doen, is op de bonnefooi een Excelletje in elkaar flansen, en als dat niet goed werkt de conclusie trekken dat het in een ander pakket moet worden gemaakt. Ik zeg niet dat het bij jullie zo is gegaan, maar het is mogelijk :). Je gaat dan van verkeerde uitgangspunten uit.

Het kan uiteraard prima in Access, laat dat duidelijk zijn. En we helpen je er graag bij :).
 
De code die gebruikt is kan ik niet doorgronden, hoe die dan zou moeten worden kom ik ook niet uit.
Zie iemand nogmaals kunnen helpen?

Die code zou er volgens mij zo uit kunnen zien:
Code:
Private Sub KeuringAanmaken_Click()
    Dim KeurID As Long
    
    'Keuring toevoegen voor de macine op het formulier
    DoCmd.RunSQL "INSERT INTO TBL_Keuring (ID_Machine) VALUES (" & Me.ID_Machine & ")"
    
    'ID van de toegevoegde keuring ophalen
    KeurID = DMax("ID_Keuring", "TBL_Keuring")

    'controles toevoegen
    DoCmd.RunSQL "INSERT INTO TBL_KeuringDetail (ID_Keuring, ID_Controlesoort) " & _
        "SELECT " & KeurID & ", TBL_Controlesoort.ID_Controlesoort " & _
        "FROM TBL_Controlesoort INNER JOIN TBL_VereisteControle " & _
        "ON TBL_Controlesoort.ID_Controlesoort = TBL_VereisteControle.ID_Controlesoort " & _
        "WHERE TBL_VereisteControle.ID_Machinesoort = " & Me.Keuzelijst35
        
    'keuring zichtbaar maken op subformulier
    Me.Form.Keuring.Requery
    
    'Keuringformulier openen
    DoCmd.OpenForm "FRM_Keuring_Bewerken", , , "ID_Keuring = " & KeurID
End Sub

Merk op dat ik de knop een zinvolle naam heb gegeven. "Knop44" zegt je over een poosje niets meer. Net zomin als Keuzelijst35 trouwens.
 
Laatst bewerkt:
In alle jaren dat ik databases maak en heb gemaakt, heb ik nog nooit code nodig gehad om vanuit een (sub)formulier records aan te maken zoals Peter het nu voorstelt. Dat kun je gewoon doen met de standaard functionaliteit die in Access zit. Als jij (of Peter) denkt dat het echt zo moet, dan mankeert er iets substantieels aan de database.
Ik heb vanwege een computer probleem niet naar je db kunnen kijken, maar dat komt dit weekend nog wel. Maar ik vermoed dat je op een heilloze weg zit, waarbij je met elke aanpassing alleen maar verder van een goede database afdwaalt.
 
Ik denk dat je de essentie van de oplossing even mist. Het feit dat je er niet naar gekeken hebt zegt al genoeg :shocked:

Wat er gebeurt is dat er bij een machine een keuring wordt toegevoegd. Oké dat kan via het subformulier (keuringen bij machine) en was ook mijn voorstel, maar TS wil het met een knop, dus code.

Waar het echt zinvol is om via code records toe te voegen is wanneer bij de keuring de uit te voeren controles vastgelegd moeten worden. Dat kunnen er wel 20 per keuring zijn. Welke controles gedaan moeten worden is afhankelijk van het soort te keuren machine. De regels hiervoor staan ook in de database. Die controles verschijnen uiteindelijk op het subformulier controles bij de keuring. De gebruiker kan daar de resultaten van de controles vastleggen.
Het is natuurlijk onzin om de gebruiker alle controles in te laten voeren. Het is veel werk (ook uitzoeken welke) en foutgevoelig.
 
Laatst bewerkt:
@Peter: Ik heb toch al de naam, dus ik hoef me niet meer in te houden: ik vind dit een onzin antwoord. Als je mijn antwoorden hebt gelezen, dan had je geweten dat in mijn voorgestelde opzet je controles per machinesoort vast legt. Bij het kiezen van een machine weet je dus (en Access ook :)) welke controles daar bij horen, en die worden dan automatisch op het subformulier te laden. Daar hoef je weinig voor te programmeren.

Als een TS (of opdrachtgever) mij om een knop vraagt en hij/zij kan niet uitleggen waarom dat met een knop moet, dan krijgt-ie hem bij mij niet. Zo simpel werkt dat. Ik bouw geen onzin in als het niet nodig is. Het maakt het onderhoud van het systeem alleen maar nodeloos moeilijker. Er zit geen functionele winst aan, en geen tijdwinst. Kom op zeg, dan bouw je dat toch niet?
 
Ik volsta met te verwijzen naar post #14 (ik geef toe:lang geleden) waarin ik het verschil uitleg tussen de vereiste controles per machinesoort en de daadwerkelijke uit te voeren/uitgevoerde controles per keuring (waarbij je ook de bevindingen kwijttkunt).
 
Goedemorgen,

Die code zou er volgens mij zo uit kunnen zien:
De code die hierbij is vermeld is wat mij betreft perfect.
Ook voor de gebruiker "overzichtelijker" dan via het sub formulier.

Wat je eigenlijk niet moet doen, is op de bonnefooi een Excelletje in elkaar flansen, en als dat niet goed werkt de conclusie trekken dat het in een ander pakket moet worden gemaakt. Ik zeg niet dat het bij jullie zo is gegaan, maar het is mogelijk . Je gaat dan van verkeerde uitgangspunten uit.
Dit was nog beroerder, het stond wel in Excel, niet door ons gemaakt, maar dat was om het uit te draaien en op papier af te vinken en in te vullen :d

Met hetgeen ik nu heb ga ik aan het testen en rest mij nog wat meer zoekfuncties en rapporten in te bouwen.

Bedankt voor de geboden hulp.
 
Goedemorgen,

De onderstaande code die dus onder de veelbesproken knop zit geeft/gaf nog een raar probleem.
Op het moment dat ik er op klik "springt" hij eerst naar een andere machine die al eerder is ingevoerd.
De controles die hij moet toevoegen komen dan ook in de verkeerde machine terecht.

Ik heb geprobeerd om bovenin de code "Me.Requery" toe te voegen, dat mocht niet helpen.
Als ik de machine sluit en weer open dan gaat het wel goed.
Dat zou ik dus elke keer kunnen doen bij een nieuwe machine....:rolleyes:

Code:
Private Sub KeuringAanmaken_Click()
Dim KeurID As Long

    'Keuring toevoegen voor de macine op het formulier
    DoCmd.RunSQL "INSERT INTO TBL_Keuring (ID_Machine) VALUES (" & Me.ID_Machine & ")"
    
    'ID van de toegevoegde keuring ophalen
    KeurID = DMax("ID_Keuring", "TBL_Keuring")

    'controles toevoegen
    DoCmd.RunSQL "INSERT INTO TBL_KeuringDetail (ID_Keuring, ID_Controlesoort) " & _
        "SELECT " & KeurID & ", TBL_Controlesoort.ID_Controlesoort " & _
        "FROM TBL_Controlesoort INNER JOIN TBL_VereisteControle " & _
        "ON TBL_Controlesoort.ID_Controlesoort = TBL_VereisteControle.ID_Controlesoort " & _
        "WHERE TBL_VereisteControle.ID_Machinesoort = " & Me.Keuzelijst35
        
    'keuring zichtbaar maken op subformulier
    Me.Form.Keuring.Requery
    
    'Keuringformulier openen
    DoCmd.OpenForm "FRM_Keuring_Bewerken", , , "ID_Keuring = " & KeurID
End Sub

Nu heb ik de code "Me.Refresh" vooraan toegevoegd, nu gaat het wel goed :thumb:
 
Ik had het alleen getest met bestaande machines.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan