pannenkoekenhuisdatabase

[blablaman]

Hallo, ik ben een database aan het maken om bestelling in op te nemen. Het idee is om personeel door het pannenkoekenhuis te laten lopen met mobile terminals en daarmee bestelling in de database te laten plaatsen .

De tabelen die nodig zijn heb ik al gemaakt. Alleen ik weet niet zo goed hoe ik het beste formulieren erbij kan maken.

omdat ik als ik een bestelling ga plaatsen met bestelnummer tafelnummer aantal en de consuptie krijg ik een melding van kan record niet toevoegen omdat er geen bestelnummer in besteldatum staat.

Ik had zelf ongeveer bedacht te gaan werken met subform maar dat lukt niet echt.

Kan iemand mijn tips of voorbeelden geven. Ik heb mijn database maar even toegevoegd. Alvast bedankt

 

[OctaFish]

Kun je eerst uitleggen waarom je de tabellen aan elkaar hebt gekoppeld op deze manier? Ik zie er namelijk niet heel veel logica in, dus die wil ik eerst zien. En dan met name de tabellen Besteldatum en Betaaldatum.

 

[blablaman]

Deze database structuur komt voort uit het programma casetalk wat ik heb geleert te gebruiken. In dat programma vul je gewone zinnen in zoals Tafel 19 besteld op 27-december 2009 om 12:35. De waarde Tafel 19, 27-december 2009 en 12:35 geef je een naam. Het programma koppeld al deze waarde logies aanelkaar en zo krijg je een database structuur die op deze lijkt.

zo zijn die 2 datum tabellen dus gekomen. Maar als je ze in de hoofdtabel zet en dan gaat normaliseren komen je volgens mij ook op dit uit.

groetjes

 

[blablaman]

ik wordt intussen echt gek van dit probleem.
Ik heb het volgende bedacht en geprobeert.

Als ik een formulier maak met bestelnummer, tafelnummer, besteldatum en besteltijd. Dan wil ik via een subformulier de consumptieaantal en consumptienaam invoeren.

Maar dat doet hij niet want er bestaat nog geen record in besteldatum-tabel.

Ik dacht dus de bestelling in een query te zetten die ik nadat ik dus een record in besteldatum-tabel hebt toevoegd deze te laten verplaatsen.

Ik heb alleen geen idee hoe ik dit zou moeten doen.

iemand tips of een beter idee misschien
alvast bedankt

 

[OctaFish]

Ik snap nog steeds niet helemaal waarom je deze structuur gebruikt, maar dat hij problemen geeft, geloof ik graag!
Ik zou om te beginnen toch echt alle Bestellingsgegevens in één tabel opslaan. Er is geen enkele reden te bedenken om dat niet te doen, behalve dus als je het heel erg moeilijk voor jezelf wilt maken...
Normaliseren van een proces houdt ook in, dat je nadenkt over de processen, en welke interactie er is tussen de verschillende gegevens. Eén van de vragen die je moet stellen is dus: welke gegevens horen logisch bij elkaar? Bijvoorbeeld: alle klantgegevens in één tabel, alle bestelgegevens in één tabel, alle facturen in een eigen tabel, etc.

 

[blablaman]

weet iemand hoe ik dit kan doen.

Ik heb een formulier met een textbox. Ik wil graag als ik hier iets op invul dit door wordt gegeven aan het subformulier ook een textbox wat op het zelfde formulier staan.

iemand een idee.

 

[OctaFish]

Heb je nog iets veranderd aan de opzet die je eerder hebt gepost?

 

[blablaman]

nee.

ik een formulier gemaakt met een knop erop die als er op klikt een record aanmaakt in tabel besteldatum. Dan doorlinkt naar de form waar je een de besteldatum form krijgt met een subform van bestelling waar je dan de bestelling kan invoeren.

dus de hoofdfunctie werkt nu. Maar de bedoeling is dat er een form/rapport in de keuken komt en dan de pannenkoeken laat zien die moeten worden gemaakt.

Alleen met de functie die ik nu hebt worden op dit form/rapport dan meteen de bestelling laten zien maar als de bestelling op dat moment dan wordt aangepast wordt er een foute pannenkoek gemaakt.

ik zou graag willen dat de bestelling worden opgenomen en dan de bestelling in 1 keer opslaan. Ik heb z'n functie gezien in een topic over formulieren verversen.

ik heb de database wat ik totnutoe heb even upgeload. Er staan ook andere form in die geen functie meer heeft. deze ben ik vergeten te verwijderen. sorry daarvoor.
Het gaat daarbij om formulier1 en bestelling1 en bestelling opnemen

 

[blablaman]

Oke, ik ben er bijna. Ik heb alleen nog een klein beetje hulp nodig.

Ik heb nou een form met een knop als je daaropklikt voegt hij een nieuwe regel toe in besteldatum en het getal is eentje hoger. dan linkt hij door naar een andere form, waar je de bestelling kan toevoegen. Zonder dat het direct in de tabel zit. Ik zit met 2 problemen. Je kan alle andere bestelling ook zien. Dit dacht ik op te lossen met een query maar dat lukt niet helemaal en als ik het wil opslaan (in tabel) dan verdwijnt het bestelnummer.

alvast bedankt

 

[Greenery80]

Hoi Blablaman,

zoals Octafish stelde geeft de huidige structuur problemen.
Mijn mening is ook dat je hier echt iets aan moet doen. Even een vergelijking met het bouwen van een huis om het duidelijk te maken: Als de fundering slecht is, moet je gewoonweg niet verder bouwen. Zorg dus eerst dat de basis in orde is (dus nog niet beginnen met queries, formulieren, rapporten, macro's, procedures en functies). Kortom je moet echt even terug gaan naar de tekentafel.

Ik zal een aantal problemen hieronder even kort benoemen:

Tabellen

tblContacts
Ik begrijp niet goed wat je met deze tabel wilt. Ik ga er overigens even vanuit dat dit een tabel is met klanten en dus niet medewerkers. Deze tabel is ook nergens aan gekoppeld (relatie) en ik vraag me ook ernstig af of je deze tabel wel in deze database moet stoppen.
Het lijkt mij ook handiger en makkelijker om alleen zaken als tafel en bestellingen bij te houden. Klanten zijn dan dus redelijk anoniem.
En ik neem even aan dat jullie niet om adresgegevens vragen bij een bestelling?
Let wel: dit is maar een tip. Het is namelijk sterk afhankelijk van wat je wilt met deze db.

tblBestelling
De tabel tblBestelling heeft geen unieke id. Dit is een volgens mij een probleem als men bijvoorbeeld apart wil afrekenen. Gelukkig gebeurd dit bijna nooit in Nederland... (Going dutch?)

tblBesteldatum
Veld tafel moet (denk ik) verwijderd worden uit deze tabel, want een grote groep mensen kan vast aan meerdere tafels zitten bij 1 bestelling. Maar ik kan het mis hebben -> als jullie altijd alles noteren op 1 tafel.

Veldnotatie in tabellen
Een aantal velden zijn volgens mij numerieke velden en dus geen tekst velden.
En voor datum en tijd velden zou ik ook gebruik maken van datum/tijd notatie ipv tekst.

Relaties
Er is geen sprake van referentiële integriteit tussen tblBestelling en tblBesteldatum.
Er is geen sprake van referentiële integriteit tussen tblBestelling en tblBetaaldatum.

Naamgeving tabellen
Ik heb hier nog even een apart kopje voor gemaakt, omdat ik dit verwarrend vind in deze database. tblBesteldatum is namelijk de tabel Bestellingen (hier staan de unieke gegevens in van een bestelling: Nummer, datum, en tijd). En tblBestelling is eigenlijk Bestellingonderdelen (verschillende bestelde gerechten per bestelling).


Ik denk dat dit eerst wel genoeg stof is om even over na te denken.
Ik ben zeker wel wat vergeten en ik heb vast wat denkfouten gemaakt.
Maar dat krijg ik dan wel te horen van jou, Octafish of van de vele anderen op dit forum.

Ik heb (zoals je kunt merken) ook nog weinig aandacht besteedt aan het afrekenen. Maar je moet echt oa ook nog even nadenken over aparte betalingen. Voorbeeld: Persoon 1 en 2 zitten aan één tafel en zijn van verschillende bedrijven en moeten ook apart declareren en dus ook apart afrekenen. Momenteel is dit niet mogelijk.
De vraag die hier eigenlijk uit voort komt is: wat wil jij met betalingen?

Ik heb nu geen tijd meer... Maar het idee lijkt me duidelijk.

Ik hoop in ieder geval dat je hiermee een beetje geholpen bent.

 

[OctaFish]

Waarvan Akte!

 

[blablaman]

bedankt voor je informatie.
tblcontacts hoort er helemaal niet in. Deze zat erin om een formulier te testen die ik eruit had gegooid.

Over het afrekenen daar mocht gewoon 1 rekening per bestelling komen maar dit kan eventuel op worden gelost met een nieuwe veld bij bestelling met persoonnummer.

Over de database structuur het volgende

Dit plaatje had ik gevonden toen ik nog moest beginnen. Toen kreeg ik te horen dat ik gebruik moest maken van het programma casetalk. En die gaf mij de databasestructuur zoals hij nu is. Als je kijkt komt het volgens mij redelijk overheen met mijn database en dit plaatje. tabel klanten even weg denken want die is niet nodig.
Dus ik weet niet wat ik anders aan deze database structuur moet doen.
Als u andere tips heeft over de database stuctuur hoor ik het graag. Anders wilt u even kijken naar de form, VBA enz enz

alvast bedankt

 

[Greenery80]

De situatie word mij al iets duidelijker.

Ik had ook al wel een vermoeden dat tblContacts inclusief formulier niet in deze db thuis hoorde. Dit had Octafish ooit eens gepost in een voorbeeld over verschil tussen Bound en Unbound forms.

Over het afrekenen daar mocht gewoon 1 rekening per bestelling komen maar dit kan eventuel op worden gelost met een nieuwe veld bij bestelling met persoonnummer.

Ik begrijp hieruit dat je in tblBestelling een persoonnummer wilt toevoegen. Waarschijnlijk bedoel je klant: klant 1, 2, 3, etc. Ik ben het met je eens dat dit een mogelijke oplossing is.

Laat ik nog even een vraag benoemen waar ik mee zit: Wat wil je doen met personeel in deze db? Het lijkt mij handig om te noteren wie van de bediening de order opneemt en eventueel wie de afrekening voor zn rekening heeft genomen. Maar misschien vind je dit geen interessante info, kan ik me ook iets bij voorstellen (alleen noteren dat de bestelling is opgenomen en betaald). Ik probeer een beetje mee te denken...

Ik begin nu ook een beeld te krijgen van de tabel tblBetaaldatum.
Je stelt dat er maar 1 rekening is per bestelling. Je kunt dan volgens mij de tabel tblBetaaldatum verwijderen (gegevens zijn identiek -> ik heb ook zo'n vermoeden dat Octafish hier al op doelde met zijn 1e en 2e posting...)! En waarschijnlijk wil je wel de tijd noteren van de betaling, maar dan in de tabel tblBestellingdatum (en de rest vervalt, want afrekendatum is waarschijnlijk altijd gelijk aan de besteldatum (?) en tafel wordt bijgehouden in tblBestelling).
Maar ook dit is een afweging die jijzelf moet maken, want jouw db moet een afspiegeling zijn van de werkelijke/gewenste situatie.

Ik zal ook nog even ingaan op het plaatje:
Het idee komt wel redelijk overeen, afgezien van de relaties tussen tblBetaaldatum & tblBesteldatum en tblBestelling. Tevens wordt het veld tafel in 3 tabellen genoteerd ipv in 1 tabel. Ik vermoed nu dat de tabel tblBetaaldatum niet nodig is in deze db. En je hebt zelf al gesteld dat tblContacts niet in deze db moet. Kortom er zijn wel wat verschillen.

Als je de eerder genoemde tips en degene vermeld in deze post verder uitwerkt (en eventueel implementeert), vermoed ik dat je al iets dichter bij het gewenste resultaat komt.

 

[blablaman]

De situatie word mij al iets duidelijker.

Ik had ook al wel een vermoeden dat tblContacts inclusief formulier niet in deze db thuis hoorde. Dit had Octafish ooit eens gepost in een voorbeeld over verschil tussen Bound en Unbound forms.


Ik begrijp hieruit dat je in tblBestelling een persoonnummer wilt toevoegen. Waarschijnlijk bedoel je klant: klant 1, 2, 3, etc. Ik ben het met je eens dat dit een mogelijke oplossing is.

ook mooi dat kan dan eventuel ook erin.

Laat ik nog even een vraag benoemen waar ik mee zit: Wat wil je doen met personeel in deze db? Het lijkt mij handig om te noteren wie van de bediening de order opneemt en eventueel wie de afrekening voor zn rekening heeft genomen. Maar misschien vind je dit geen interessante info, kan ik me ook iets bij voorstellen (alleen noteren dat de bestelling is opgenomen en betaald). Ik probeer een beetje mee te denken...

personeel is niet belangrijk. En de database gaat alleen over de bestellingen

Ik begin nu ook een beeld te krijgen van de tabel tblBetaaldatum.
Je stelt dat er maar 1 rekening is per bestelling. Je kunt dan volgens mij de tabel tblBetaaldatum verwijderen (gegevens zijn identiek -> ik heb ook zo'n vermoeden dat Octafish hier al op doelde met zijn 1e en 2e posting...)! En waarschijnlijk wil je wel de tijd noteren van de betaling, maar dan in de tabel tblBestellingdatum (en de rest vervalt, want afrekendatum is waarschijnlijk altijd gelijk aan de besteldatum (?) en tafel wordt bijgehouden in tblBestelling).
Maar ook dit is een afweging die jijzelf moet maken, want jouw db moet een afspiegeling zijn van de werkelijke/gewenste situatie.

Nee, De bedoeling is het volgende:Als iemand aan een tafel gaat zitten komt er een ober aan die neemt de bestelling op en als die op een knop bestellen druk wordt er in tabel besteldatum de datum en tijd van de bestelling eringezet. als er bij de kassa wordt betaald wordt die bestelnummer afgesloten door in tabel betaaldatum die datum en tijd van de betaling.
Dus besteldatum en betaaldatum kan dus nooit gelijk zijn.

Ik zal ook nog even ingaan op het plaatje:
Het idee komt wel redelijk overeen, afgezien van de relaties tussen tblBetaaldatum & tblBesteldatum en tblBestelling. Tevens wordt het veld tafel in 3 tabellen genoteerd ipv in 1 tabel. Ik vermoed nu dat de tabel tblBetaaldatum niet nodig is in deze db. En je hebt zelf al gesteld dat tblContacts niet in deze db moet. Kortom er zijn wel wat verschillen.

met de tips uit de vorige post heb ik al wat mee gedaan

Als je de eerder genoemde tips en degene vermeld in deze post verder uitwerkt (en eventueel implementeert), vermoed ik dat je al iets dichter bij het gewenste resultaat komt.

EDIT:
Ik heb even mijn database tot nu weer even toegevoegd. en wat met je tips gedaan. Alleen bij bestelling heb ik de tafel er in laten staan dat zie je wel waarom via het formulier.

Ik zit nu met 2 kleine probleempjes. Ik wil graag als ik dus de bestelling invoer niet meteen in de tabel komt maar pas nadat ik op een knop gedrukt hebt.kan iemand me daarbij helpen??


alsvast bedankt

 

[OctaFish]

En wat is het tweede probleem?

Wat betreft het eerste probleem: de oplossing daarvan zat in het formulier en de tabel die je er uit hebt gegooid. Je moet, om de recordset op te slaan met de knop, het formulier loskoppelen van de onderliggende tabel. Daarmee maak je het formulier onafhankelijk van een tabel. Daarna moet je uiteraard de gegevens die op het formulier staan alsnog inlezen, en opslaan.
Bij een doorlopend formulier is dat wat ingewikkelder dan bij een enkelvoudig formulier, omdat je waarschijnlijk eerst alle gegevens van de bestellingregels wilt invoeren, en dan alles in één keer wegschrijven.