Formulier en subformulier gezamenlijk opslaan in Access

Status
Niet open voor verdere reacties.
E

eldik134

Gebruiker
Lid geworden
28 okt 2013
Berichten
6
Goedemiddag,

Ik heb een vraag over een database welke ik aan het ontwikkelen ben voor mijn onderneming. Ik heb wel Access gehad bij mijn opleiding maar het is allemaal een beetje verwaterd ben ik bang:o

Het bestand zo ver is bijgesloten. De bedoeling is een klantbeheer systeem met daaraan gekoppeld een "verzend lijst". De verzend lijst bevat de artikelen die wekelijks verzonden worden naar de klanten. Deze bestellingen zijn iedere week anders.

Inmiddels heb ik een tabel Klanten, Chauffeur, Dagen, Weken en Jaren en een gecombineerde tabel om de verzendlijst samen te stellen (klant - Datum - Bestelling).

Nu heb ik een formulier gemaakt genaamd Klanten. Middels dit formulier is het mogelijk de reeds opgeslagen klanten per record te bekijken en of een record toe te voegen in de Tabel Klanten.
In dit formulier heb ik een Sub-formulier gemaakt op basis van een query die de gegevens van de bestelling laad uit de gecombineerde tabel op basis van de relatie klant_id.
Zo ver werkt dit goed zoals ik zou willen. De gegevens uit de gecombineerde tabel worden netjes opgehaald en per klant_id gefilterd middels een Where statement in de query. Hierbij is het ook mogelijk de week en het jaartal op te geven. Ook dat gaat goed.

Maar nu wil ik een nieuwe klant aanmaken in het formulier en daarbij een bestelling in voeren in het subformulier. Dit werkt echter niet. De klant word opgeslagen maar als ik iets wil invoeren in het sub-formulier krijg ik de melding de Join-sleutel komt niet voor in de record set.

Het zou mooi zijn als iemand een oplossing heeft voor bovenstaande.

Alvast bedankt,

Groet guido


Download hier het bestand: http://www60.zippyshare.com/v/43109909/file.html
 
Welkom op Helpmij.nl. :)

Ik heb je vraag naar de Access afdeling verplaatst.
 
Ik kan pas vanavond naar de db kijken (verkeerde versie) maar er valt uit je verhaal al wel wat op te maken.
eldik134 zei:
Inmiddels heb ik een tabel Klanten, Chauffeur, Dagen, Weken en Jaren en een gecombineerde tabel om de verzendlijst samen te stellen (klant - Datum - Bestelling).
Klik om te vergroten...

Waarom de tabellen [Dagen], [Weken] en [Jaren]? Die zijn normaal gesproken absoluut niet nodig. En in jouw geval ook niet, want je hebt in de tabel KlantBestelling al een veld [Datum]. En een datum bestaat,zoals je weet, uit een dag, een maand en een jaar. Dus je weet al welke dag, welk jaar en welke week (kun je simpel berekenen op basis van de datum) het is. En voordat je antwoord: die heb ik nodig om te filteren: voor je filters kun je de gewenste gegevens simpel uit de tabel trekken.
Tweede punt: je subformulier hoef je niet te filteren op [klant_id] met een WHERE. Als je het subformulier correct koppelt aan het hoofdformulier, zie je alleen maar de bestellingen die bij de klant horen. Zonder filter dus.

Dan de echte vraag: Als je het subformulier op de juiste wijze koppelt aan het hoofdformulier, kun je probleemloos records toevoegen aan dat subformulier.
 
Oke, duidelijk.

Ik begrijp je standpunt over de datum. Ik heb hier zelf over nagedacht maar de database wordt een vervanger van de excel lijst waar ik nu mee werk. Ik heb een voorbeeld van de excel lijst toegevoegd om je een idee te geven hoe ik nu werk. De vraag gaat in dit geval op klant niveau maar de gegevens blijven hetzelfde uiteraard.

voorbeeld_verzendlijst.jpg

Ik kwam naar mijn mening tot de conclusie dat ik de database beter met losse dagen - weken - jaren kon maken, mede omdat het in dit geval niet om exacte datums gaat. Het veld datum bestaat ook niet in mijn database (sorry voor de verwarring). Het zijn losse velden van dag - week en jaar. Ik wil het mezelf niet te moeilijk maken voorlopig. Straks is het de bedoeling dat ik door middel van een button een complete week kan kopiëren naar een volgende week, omdat de bestellingen in de basis altijd vrijwel gelijk zijn. Dan lijkt mij een selectie van een week het makkelijkst om mee te werken ipv eerst te moeten filteren op datum etc.

Ik begrijp wel wat je met je laatste opmerking bedoeld. Als ik het goed begrijp hoef ik geen subformulier op basis van een query te maken, maar kan ik het subformulier direct opmaken uit de gecombineerde tabel?
Ik heb nu niet de mogelijkheid om dat te proberen, maar daar ga ik vanavond mee aan de gang.
 
eldik134 zei:
... maar de database wordt een vervanger van de excel lijst waar ik nu mee werk.
Klik om te vergroten...
De auto is de vervanger van koets+paard, maar geen autofabrikant haalt het in zijn hoofd om er een voederbak met haver in te zetten. Nieuwe applicatie=nieuw ontwerp dus.
eldik134 zei:
Het veld datum bestaat ook niet in mijn database
Klik om te vergroten...
Dan zou ik dat er maar snel inzetten. En die andere velden er dus uit.
Je Excel voorbeeldje is een scherm dat zowiezo op die manier nooit in Access gebouwd kan/moet/mag worden. Totaal ongeschikt voor een database. Klant 4 bestelt zo te zien op woensdag twee zakken van 2,5 kg, één fijn en één middel. In Access maak je daarvoor 1 record in de tabel Bestellingen, en 2 records in de tabel BestelRegels (die jij als ik het goed snap nog niet hebt). Wil je een overzicht van een weekrooster, dan maak je dat op basis van een rapport.
 
Zou je een voorbeeld kunnen geven van een record in de tabel Bestellingen en een voorbeeld van een record in de tabel BestelRegels?

Ik wil graag weten wat je in welke tabel zou plaatsen. Worden meerdere records BestelRegels middels een id gekoppeld aan een uniek Bestellingen id?
 
Helemaal juist. Een bestelling bevat de generieke bestelgegevens, zoals de datum, klant, bestelnr etc. Ik twijfel nog over een veld als Afleveradres, omdat je dat nog op bestelregelniveau kan gebruiken. Je kunt bijvoorbeeld tegen de klant zeggen dat alle artikelen altijd op één adres worden afgeleverd, en in dat geval is het afleveradres bestellingspecifiek. Je slaat het dan op in de tabel [Bestellingen]. Of je spreekt af dat verschillende artikelen op verschillende adressen afgeleverd kunnen worden, en in dat geval is het afleveradres afhankelijk van het artikel. En sla je het op in de tabel BestellingRegels. Vanwege dit soort vraagstukken is het bijna ondoenlijk om een algemene opzet te maken, omdat er veel te veel variabelen zijn die afhankelijk zijn van de bedrijfseigen processen. Die moet je dus sowieso eerst in kaart hebben/brengen.
Maar wat je in ieder geval in een tabel [Bestelregels] opneemt:
1. Bestelnummer
2. Artikelnummer
3. Aantal besteld
4. ArtikelPrijs

Verder kun je nog denken over staffelkorting, zoals hierboven al uitgelegd eventueel afleveradres, gewicht zou nog kunnen, als je dat niet uit de tabel Artikelen kan herleiden. Je zou bijvoorbeeld een artikel <****ake> kunnen hebben, daar een vaste prijs voor hebben. Bij Aantal geef je dan het gewicht in, en de prijs is dan [Gewicht] * [Prijs]. Of je hebt in de tabel [Artikelen] voor elke gewichtsklasse van <****ake> een apart record, met een aparte prijs. Zoals ik al zei: er zijn zoveel variabelen, dat het ondoenlijk is om daar een voorbeeldje bij te verzinnen. Zelf heb ik een db in gebruik gehad voor computerartikelen. Die was dan weer relatief simpel, al zit je dan met het probleem dat nogal wat artikelen snel verouderen, zodat het artikelbeheer behoorlijk intensief was. Om over de wisselende inkoopprijzen maar te zwijgen...
Common Sense, daar kom je meestal een heel eind mee.
 
Bedankt weer zover!:thumb:

Ik ben inmiddels weer aan de gang met mijn database. Ik heb een aantal aanpassingen gedaan op basis op basis van hetgeen bovenstaande beschreven.

Inmiddels heb ik de volgende tabellen:
Klanten
Chauffeur
Artikelen
Bestellingen
BestelRegels

Bestellingen bestaat uit de volgende velden:
Klant, Chauffeur, Datum en Bestelnummer

BestelRegels bestaat uit de volgende velden:
Artikel, Aantal, Bestelnummer

Alles gaat goed met de relaties, Klanten worden geladen evenals de chauffeurs en de Artikelen.

Nu heb ik er over nagedacht maar kom er niet uit hoe ik de BestelRegels kan koppelen aan de Bestelling.
Ik heb nu dus 2 lege tabellen, op wat voor manier kan ik die vullen zodat de BestelRegels gevuld worden en er automatisch een Bestelling wordt aangemaakt in de tabel Bestellingen op basis van het bestelnummer in BestelRegels?

Beetje verwarrende vraag maar ik hoop dat ik het zo goed heb uitgelegd.
 
Doorgaans maak je voor de tabel Bestellingen een enkelvoudig formulier, en voor de tabel Bestelregels een doorlopend formulier. In het ontwerpscherm van het formulier Bestellingen sleep je dan het formulier Bestelregels naar de detailsectie. Access zal ze dan automatisch koppelen op basis van het bestelnummer. Nu kun je een nieuwe bestelling maken, en in het subformulier gelijk detailrcords toevoegen.
 
Hoi Octa,

Je advies gevolgd en inderdaad kan ik in 1 form met sub-form een bestelling invoegen.

Echter de Bestelling_id in het hoofd formulier moet eigenlijk automatisch gevuld worden met de dan toe hoogste waarde in Bestellingen + 1. Maar mijn id in bestellingen is uniek en autonummering. Kan ik het beste ID weg doen en Bestelling_ID prim key maken met autonummering?

Wat tevens fout gaat is dat wanneer ik een nieuwe bestelling toevoeg, en dit komt dan ook in de tabellen te staan, en ik vervolgens terug ga naar het hoofd formulier, die de Bestelling gegevens wel kan raadplegen, maar de BestelRegels is die weer "vergeten".

Hierbij het huidige bestand:
http://www32.zippyshare.com/v/61175288/file.html
 
Ik heb je db even bekeken, en gelijk maar één aanpassing gemaakt: in al je tabellen de Opzoeklijsten in tabellen verwijderd. Ik vind dat je in tabellen geen opzoeklijsten moet gebruiken, omdat je dan nooit kunt zien wat je nu in die tabel opslaat. Nog af gezien van het feit dat je er later in exports en queris groete problemen mee gaat krijgen. Dus onthoud: in tabellen alleen tekstvelden gebruiken, tenzij het een opzoekveld is op basis van een lijst met waarden. Voor bijvoorbeeld [Betaalwijze], een tabel met 3 keuzes, is het niet nodig om een tabel te gebruiken, maar kun je net zo goed een Lijst met waarden gebruiken. Tenzij je die lijst in 30 tabellen nodig hebt, dan is een brontabel weer handig (bijvoorbeeld als je opties gaat wijzigen of uitbreiden).

Verder zie ik in je tabel Bestellingen velden als DagID, WeekID en JaarID, maar mis ik een veld Besteldatum!! Terwijl je besteldatum nu juist een cruciaal veld is voor bestellingen! Hoe weet je anders de besteldatum? Dus die heb ik er ook maar uitgegooid en vervangen door één datumveld.

Als laatste je vraag over het bestelID: als je daar een autonummer veld voor gebruikt, krijg je per definitie een oplopend nummer. Alleen als je aan het klooien bent met de db (en dat doe je in de bouw- en testfase) dan raak je nummers kwijt als je records weggooit. Kun je oplossen door vóór het live gaan alle testdata er uit te gooien, en de db te comprimeren. Dan worden als het goed is ook alle autonummervelden gereset, en begint de teller weer netjes met 1.
Wil je een andere nummering (bijvoorbeeld elk jaar opnieuw met 1 beginnen), dan moet je zelf een nummer gaan genereren. Dat kan met een daartoe gemaakte functie. Hoe die werkt, is afhankelijk van de gewenste nummerstijl en opmaak.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan