keuze in keuzelijst maar in een record te kiezen, daarna uit keuze lijst

Hallo
Ik ben maar een eenvoudige acces gebruiker en VBA gaat me echt boven mijn pet, dus ik hoop dat er een eenvoudige oplossing is voor mijn vraag.
Ik ben nieuw hier dus sorry als ik dingen nietg goed formuleer

ik heb een formulier waarmee je vooraf een frietbestelling doet, voor een dag later, op een bepaald tijdstip, hierin heb ik een keuzelijst die uit een andere tabel de beschikbare levertijden haald, dit is via een selectie query die door middel van een ja/nee veld de beschikbare tijden selecteerd

mijn vraag is of het mogelijk is om een gekoze tijdstip bij het invullen van de volgende bestelling niet meer in de keuzelijst te tonen

zelf dacht ik aan een extra ja/nee veld in de tabel met tijden, waarbij de ja naar nee omschakeld bij de keuze van dat record, maar geen idee of en zo ja hoe dit mogelijk is

o ja het gaat om een acces 2016 database

met vriendelijke groet,

peter

Allereerst welkom bij HelpMij! Als antwoord op je vraag: ja, dat kan. Maar je zult de oplossing vrees ik moeten programmeren omdat je dynamisch gaat rommelen aan de keuzelijst. En dat kan alleen als je gaat programmeren. Als je dat zelf niet kan, en daar lijkt het op gezien je opmerking, dan zou ik zeggen: post de db ook mee, met wat dummydata, zodat we kunnen zien wat de beste oplossing is.

upload database lukt niet

Ik heb de database omgezet naar een zip bestand iets groter dan 2 mb maar krijg steeds de foutmelding upload mislukt

2Mb is de max, dus dat kan wel kloppen. Ik weet niet of je de db eerst gecomprimeerd hebt, maar dat scheelt aanzienlijk in de grootte als je daarna zipt. Om het probleem te bekijken hoeven er ook geen duizenden records in de db te zitten; als er maar genoeg in zit om de vraag te reproduceren is dat al genoeg. Dus eventueel nog wat records verwijderen (en dan weer comprimeren uiteraard) kan ook helpen. Verder kun je nog tabellen/formulieren/rapporten die voor de vraag niet nodig zijn ook nog verwijderen. Uiteindelijk moet je hem dan wel klein genoeg krijgen om wél te uploaden. Alternatief, als het nog steeds niet lukt, is om de zip (of db) of een fileshare te zetten.

als het goed is, is het nu wel geluktBekijk bijlage frietpizza.zip

OK, laten we eens bij het begin beginnen, want ik zie dermate veel problemen in je database, dat ik me afvraag of het zinvol is om je huidige vraag op te lossen. Het lijkt mij beter dat je eerst de basis op orde brengt.
Het grootste probleem zit 'm in het feit dat je de database totaal niet genormaliseerd hebt. Je gaat uit van een tabel [Bestelling]. Zo'n bestelling bestaat uit een aantal vaste gegevens, en een aantal variabele gegevens. Vaste gegevens zijn:
1. Besteldatum
2. KlantID
3. Leveradres
4. Levertijd

Dit zijn velden die voor elke bestelling nodig zijn. Wellicht nog meer, maar die kan je zelf wel bedenken hoop ik.

Daarnaast heb je de variabele gegevens: wat bestelt de klant, en in welke hoeveelheden, en voor welke prijs. Dat laatste sla je nu niet eens op, dus daar hebben we het nog even niet over. Het wat is natuurlijk het artikel: pizza (in verschillende varianten), friet, kipnuggets, pannenkoek, nasi, warme maaltijden. Wat hebben al die artikelen gemeen? Het zijn in beginsel dezelfde objecten. Voor de bestelling maakt het niet uit of je een Pizza Salami invoert, of een Frikandel Speciaal. Het is in beide gevallen een artikel. Eén van de (belangrijkste) regels in databases is, dat je artikelen die hetzelfde zijn, in één tabel opslaat. Maar niet als apart veld, maar als apart record. Elk artikel heeft ook weer eigen kenmerken, zoals wellicht bereidingstijd, prijs etc. Kortom: je zou een tabel [Artikelen] moeten hebben die bestaat uit deze velden:
1. ArtikelID
2. ArtikelNaam
3. ArtikelPrijs
4. Bereidingstijd

Eventueel kun je de varianten op het basisartikel nog in een tabel [ArtikelDetails] zetten, zodat je in de tabel [Artikel] allen Nasi, Pizza, Friet etc. opslaat, en in de [ArtikelDetails] dan Vegetarisch, Fromaggio, Salami, Speciaal etc. Die tabel [ArtikelDetails] ziet er dan zo uit:

1. ArtkelDetailID
2. ArtikelID
3. DetailNaam
4. Toeslag

Etc. ect. De prijs kun je op een aantal manieren berekenen: ofwel je zet de prijs in de detailtabel, zodat hij niet meer in Artikel staat, ofwel, zoals in mijn voorbeeld, je hebt een basisprijs waar je dan m.b.v. een percentage een toeslag bovenop gooit. In het laatste geval kun je voor een pizza bijvoorbeeld de losse ingrediënten die de pizza bepalen toevoegen zodat daar gelijk een aangepaste prijs uit rolt als daar een 'handgemaakte' pizza besteld wordt. Meerdere opties dus.

De [ArtikelDetails] hangt dus met een één-op-veel aan de [Artikelen]. De tabel [Artikelen] hangt op zijn beurt weer aan de tabel [Bestelregels] op basis van ArtikelID met een één-op-veel. En [Bestelregels] hangt weer met een één-op-veel aan de [Bestelling].

In essentie betekent dat dus dat je de tabellen Nasi, Pizza, etc. allemaal moet verwijderen en vervangen door één tabel. Dan ben je ook gelijk van de velden [Overige1] t/m [Overige10] af, want die horen al helemaal niet in een tabel te staan.

Laat ik beginnen met je te bedanken voor alle energie die je erin stopt, ik merk nu ook dat ik onvoldoende informatie heb gegeen over de bedoeling van de database

het is voor een camping in Frankrijk waar gezsinnen komen met kinderen met een beperking er staan 3 laptops aangesloten een voor de bar een voor beheer en een voor de gasten

het is de bedoeling dat gasten zelf hun bestellingen doen incl brood voor de volgende dag maar die tabel en formulieren zijn er uit omdat de database te groot was

Er staan geen prijzen in omdat die steeds aangepast zouden moeten worden en frankrijk 3 btw tarieven heeft die appart geregistreerd moeten worden

de klant besteld, de keuken draait het rapport van die dag uit
de bar medewerker vult het bar verbruik iedere keer

en als de gast weggaat draait de receptie het rapport totaal verbruik van die gast uit, en vult daarmee de factuur in een facturerings programma , waarmee de prijzen en de btw tarieven meteen officeel geregistreerd zijn

alle leveringen zijn dus in het restaureant, de nassi is alleen afhaal de friet en de pizza kunnen afgehaald of in het restaurant genuttigd worden, elke dag van de week is er maar 1 menu mogelijkheid

het systeem heeft al 1 jaar gewerkt, waarbij we tegen het probleem aanliepen dat er bij de friet en de pizza de kaartjes niet mee genomen werden waardoor teveel gasten op een tijdstip wilde afhalen, dit laatste zou ik willen teckelen door een gekozen tijdstip op dezelfde dag niet opnieuw gekozen kan worden

laat het me weten als ik niet duidelijk ben

OctaFish zei:

In essentie betekent dat dus dat je de tabellen Nasi, Pizza, etc. allemaal moet verwijderen en vervangen door één tabel. Dan ben je ook gelijk van de velden [Overige1] t/m [Overige10] af, want die horen al helemaal niet in een tabel te staan.

Klik om te vergroten...

de velden overig 0 t/m overig 10 staan er in om makkelijk een artikel toe te kunnen voegen tijdens het seizoen

Als de tabel goed georganiseerd is, mag dat helemaal geen probleem zijn. Je kunt bij een artikel namelijk een Ja/Nee veld zetten dat dan bijvoorbeeld [Seizoen] heet. Daar kun je dan bijvoorbeeld ook nog eens twee datumvelden bij zetten voor de begin- en einddatum zodat ze geheel automatisch te kiezen zijn. Ik heb je nadere uitleg in #7 gelezen en je onderstreept eigenlijk alleen maar de noodzaak om het opnieuw op te zetten. Ook al heeft het een jaar goed gedraaid in jouw ogen. Als ik een slechte auto maak, zal die nog gerust een jaar kunnen rijden als ik geluk heb, maar hij zal toch sneller in elkaar storten dan een goed gebouwde auto.
Het prijzenverhaal is dan voor jou inderdaad niet van toepassing, en dat maakt de db dan wel wat makkelijker. Overigens is dit:

impulsief zei:

Er staan geen prijzen in omdat die steeds aangepast zouden moeten worden en frankrijk 3 btw tarieven heeft die appart geregistreerd moeten worden

Klik om te vergroten...

eerder een uiting van onvoldoende kennis hebben van databases dan van niet kunnen maken. Als de db goed gebouwd is, kun je perfect de prijzen invoeren en onderhouden. Al ben ik benieuwd naar de frequentie:

impulsief zei:

Er staan geen prijzen in omdat die steeds aangepast zouden moeten worden en frankrijk 3 btw tarieven heeft die apart geregistreerd moeten worden

Klik om te vergroten...

Ik kan mij daar niet zoveel bij voorstellen. Wel dat je de prijzen ook in seizoenen indeelt, maar dat is dus weer perfect in de db te zetten zodat je daar ook geen fouten mee kan maken.

OctaFish zei:

eerder een uiting van onvoldoende kennis hebben van databases dan van niet kunnen maken.

Klik om te vergroten...

bovenstaand hangt natuurlijk samen, onvoldoende kennis betekend ook dat je het niet kunt maken, maar ik begrijp jou opzet van de database en ga er mee aan de slag, ik heb altijd de bestaande nog, mocht het me niet lukken

bedankt voor je hulp en je adviezen in ieder geval

En als ik er dan prijzen en btw tarieven inzet, is het dan ook op een redelijk eenvoudige manier een factuur uit te draaien, en dan bedoel ik niet of dat voor jou makkelijk is maar of het voor mij te leren is? il zit wel op LBO niveau

ik heb een kleine basis opgezet, zou jij willen kijken of dit is wat jij bedoeld, of dat ik er helemaal niks van begrijp?

Ik zal er een (kritisch ) oog op werpen als ik tijd heb!

ik denk niet dat het me gaat lukken, ik heb op basis van de nieuwe opzet van de database een bestel formulier brood voor de gasten proberen te maken, maar ik begrijp echt het voordeel van een record ten opzichte van een veld niet, beide test db s bijgevoegd.

impulsief zei:

.. maar ik begrijp echt het voordeel van een record ten opzichte van een veld niet..

Klik om te vergroten...

Als je een verkeerde database bouwt, of een database verkeerd (is niet helemaal hetzelfde) dan is dat ook lastig te zien. Maar in beginsel zouden de voordelen van een correcte database evident moeten zijn. Om maar één voordeel/voorbeeld te geven: in een genormaliseerde db is het voldoende om een nieuw record aan te maken voor een nieuw artikel. Dan werkt de database gewoon door zonder problemen. Jij zult alles wat je gebruikt moeten aanpassen: formulieren, queries en rapporten. Kortom: vanuit onderhoudsoogpunt is jouw opvatting volslagen onbruikbaar. Nu kun je zeggen: ja, maar ik verander het assortiment nooit, dus wat kan dat boeien? Dan is het antwoord: waarom gebruik je dan een database, en ga je niet in Excel werken? Dat is in jouw opzet vele malen makkelijker!
Maar ik zal uiteraard ook even naar je nieuwe opzet kijken, en daar wat tips voor geven.

dat ik het voordeel niet begrijp wil niet zeggen dat ik er het voordeel niet van in zie, maar ik begrijp niet hoe ik dat record dan in een formulier krijg en dat koppel aan een gast en dan ook nog ergens het aantal kan registreren, want daar is toch een veld voor nodig naar mijn idee