Prijslijsten

[EGeen]

Goedenavond,

Introductie:
Ik heb een probleempje, Ik heb mijn access database op ongeveer (maar simpeler) opgezet zoals het Noorderwindvoorbeeld.

Gemaakt:
3 Tabellen:
- Productlijst: met Kolommen Merk/Product/Inhoud/Prijs
- OrderTotaallijst: OrderID, KlantID, Datum
- Orderdetail: met ID, OrderID, Merk/Product/etc.
In Orderdetail komen dus meerdere dezelfde OrderID's te staan die per record het Product/inhoud etc.. weergeeft. OrderTotaal heeft dus alle orders op een rijtje.

Om dit in te vullen is er een Formulier gemaakt (met OrderTotaal)met een subformulier voor de Details van de Order.

Het Probleem:
Om dit in te vullen kan ik geen gebruik maken met de tabel met alle producten en prijzen aangezien ik alles met de hand moet invullen. Heb wel de kolommen merk producten etc. maar enkel om per record met de hand in te vullen. Wou graag de gehele productlijst gebruiken om de OrderdetailTabel in te vullen, maar enkel met de ingevulde aantal artikelen onder het goede OrderID nummer.

Ik wil dus de productlijst gebruiken ipv alles met de hand invullen.

Hoop alles een beetje goed te hebben uitgelegd.

mvg
Erwin

p.s. ben een beginneling

 

[OctaFish]

Hoi Erwin,

Alle begin is moeilijk, zullen we maar zeggen In Access lijkt alles in het begin erg complex te zijn, maar als je simpel begint, dan kun je toch al vrij snel aardige resultaten halen, en snap je nog wat je aan het doen bent ook!

Uit jouw vraag begrijp ik dat je de gegevens in het subformulier uit de tabel Produkten wilt halen, maar dat dat niet lukt.
Probeer eerst eens, in plaats van een tekstvak te gebruiken voor het veld ProduktID, met behulp van de wizard een Keuzelijst met Invoervak te maken voor dit veld. Je zult zien, dat de Wizard een mooie lijst voor je maakt, die je later eventueel nog kunt verbeteren, door bijvoorbeeld het aantal rijen te vergroten. Ik heb er een voorbeeldje bij gedaan waarin je kunt zien hoe je een keuzelijst kunt gebruiken om verschillende produktgegevens in één keer op te nemen in het subformulier.
Normaal hoef je alleen maar een verwijzing te maken naar het ProduktID om gegevens op te halen, maar als je dat doet, zul je zien dat de gegevens veranderen in je orders, als je de gegevens in de produkt tabel verandert.
Dat kan op zich geen kwaad voor zaken als produktomschrijving, maar wel voor een gegeven als de prijs van een artikel. Je wiltt uiteraard bij het maken van een order de meest recente prijs gebruiken. Als je in de tabel verwijst naar het veld Prijs in de tabel Produkt, zal je altijd, ook bij reeds geboekte orders, de huidige prijs zien, ook al is die later aangepast. Dan klopt er uiteraard niet veel meer van je administratie. Daarom wil je waarschijnlijk wel de huidige prijs opvragen, maar wil je de prijs ook in een apart veld opslaan in de tabel orderdetails.
Die techniek kun je gebruiken als je het bijgeleverde voorbeeld bestudeert.

Heb je meer vragen (en die gaan vast komen...) dan weet je nu de weg...
Succces met je database!

Michel

 

[EGeen]

Kom dr nie uit

Okee, ik dacht dat ik het begreep maar nu weet ik het niet precies meer..

Ik heb de database even bijgevoegd. Onder tabel klanten staan er normaal rond de 150 en de tabel prijzen staan rond de 1000 records. Het formulier Ordertotaal daar gaat het nu even om. Deze doet het goed, enkel als ik het met de hand invoer. Ik zou dit graag op handige wijze willen doen met behulp van de tabel prijzen. Dus wanneer er een klant binnenkomt die opschrijft, dat deze makkelijk kunnen worden ingevoerd en later weer opgehaald om te betalen.

 

[EGeen]

Niemand die mij nog een stapje verder kan helpen?

 

[OctaFish]

Ik zal er vanavond een blik op werpen.

 

[EGeen]

Als er extra informatie moet komen of iets verduidelijkt moet worden, schroom niet, ik zoek echt een oplossing...

 

[OctaFish]

Ik heb wat aanpassingen gemaakt, die je hopelijk een idee geven hoe je de database op zou kunnen zetten.
De aanpassingen betreffen voor een groot deel je tabellen. Met name de tabel Prijzen is niet handig opgezet. Omdat je veel dezelfde gegevens gebruikt, is het veel handiger om die gegevens in aparte tabellen te zetten. Ik heb daar dus een klein opzetje voor gemaakt.
Je zou eens hier kunnen kijken voor betere uitleg: Normaliseren hoe je zo iets opzet.

Als je de gegevens netjes scheidt, kun je ook op je formulieren gebruik maken van keuzelijsten om velden te vullen zonder ze in te hoeven typen. Ook daar vind je nu een paar voorbeelden van, die je kunt bestuderen.
Heb je verder nog vragen, dan kun je uiteraard altijd hier terecht!

 

[EGeen]

Zo, dat ziet er netjes uit!, Snap nog niet precies hoe ik dit na moet maken (wil zelf natuurlijk ook weten hoe en wat). Maar ben hier zeer blij mee .. Denk dat ik stuk verder kom zo. Dank u wel! (en natuurlijk alle anderen die hebben meegedacht).. Als ik er niet uitkom weet ik waar ik wezen moet!

 

[EGeen]

Helaas, open het topic toch nog even, aangezien ik er na heel veel proberen toch niet uitkom.

De tabel merk-product moet zelf worden ingevoerd?
Want ik maak het voor iemand die eigenlijk geen verstand heeft van Access(naja nog minder dan mij ). Deze moet eigenlijk niet deze merk-product tabel moeten invullen als er nieuwe producten bijkomen.
Uiteraard moet naderhand de prijs er automatisch in komen te staan.

Hopenlijk ben ik een beetje volledig. Excusses

 

[OctaFish]

Ik snap niet helemaal wat je bedoelt met je vraag.... Kan hier ook geen 2007 openen, dus dat moet tot vanavond wachten. Kan je nog even rustig nadenken over wat je bedoelt

Maar zo uit het hoofd: als je produkten hebt, kun je het merk daarbij opnemen in de tabel Produkt. Je kunt ook een aparte tabel met Merken maken, en die koppelen aan Produkten. En dan met een één op veel relatie de twee tabellen aan elkaar koppelen.
Voordeel daarvan is, dat bij het veranderen van bedrijfsgegevens, zoals een bedrijfsnaam, je dat maar op één plek hoeft te doen, namelijk in de tabel Bedrijf. Ook voorkom je dat mensen een bedrijfsnaam verkeerd invoeren. MediaMarkt is niet hetzelfde als Media Markt... Je voorkomt dus vervuiling van je tabellen.
Door het opsplitsen van gegevens hoeft het invullen niet veel ingewikkelder te worden, maar het moet uiteraard wel gebeuren.
Ik kijk vanavond nog wel verder, of het simpeler kan....

 

[EGeen]

Ik zat zelf te sneupen en dacht aan deze formule: (gehaald uit een ander topic)

Private Sub lstClubs_Click()
'Gewoon een andere recordsource instellen
lstSpelers.RowSource = " SELECT id, speler from tbl_Spelers where clubid =" & lstClubs.Value
lstSpelers.Requery
End Sub

Enkel lijkt me het dan dat hij later niet de prijzen erbij zoekt in het laatste vak
Formulier heeft : Merk-Producten-Kleur-Inhoud-Aantal-Prijzen
Waarbij de eerste 4 via een keuzetabel met invoervak uit wordt gekozen en de aantal zelf wordt ingevoerd. De prijs moet er automatisch bij komen te staan als de eerste 4 vakken zijn ingevult. (Prijsvak is voor 1 stuk)
Natuurlijk moeten enkel de producten van een bepaald merk worden uitgekozen als het merk is ingevult en niet alle producten (zijn 55 merken met in totaal toevallig exact 1000 producten)

(u merkt al, ben enthousiast begonnen, maar merk dat het op sommige punten meteen iets te hoog gegrepen is, (magoed, aldoende leert men )

 

[EGeen]

Dus eigenlijk wil ik 4 keuzelijsten met invoervak in me formulier maken, aan elkaar gelinkt. Waarna de prijs er in de laatste vak er bij komt te staan.

Keuzelijsten:
1e vak: merken
2e vak: product (maar enkel van het gekozen merk)
3e vak: inhoud (maar enkel gegeven van het gekozen product)
4e vak: kleur (snapt het idee nu wel)
5e vak: Geeft dan automatisch de prijs van het product wat op voorgaande wijze is uitgekozen.

 

[OctaFish]

Dat zijn dus keuzelijsten die van elkaar afhankelijk zijn. In het voorbeeldbestand Keuzelijsten dat je hier kunt vinden. Mocht je die al niet hebben...

 

[EGeen]

Het is een poosje geleden, maar krijg het naar veel pielen nog steeds niet voor elkaar helaas.
Er is zoveel mogelijk merk ik al. Van de Inner Join snap ik enigsinds wat het doet, enkel niet hoe ik hem aan de praat krijg. En ik vraag het me af of ik deze nodig heb.

Verder doemt zich hierbij een ander probleem op
Om een voorselectie te maken heb ik een rij ervoor gezet met de titels Lakken, Muurverven etc.
Achter lakken zitten 30 rijen met de merken sikkens, onder deze sikkensrijen zitten weer bijvoorbeeld 4 rijen met dezelfde product etc..
Deze merken staan wel afzonderlijk in een bepaalde tabel (met unieke merken dus)met de relatie naar deze hoofdtabel.
(even ter verduidelijking twee plaatjes)

 

[OctaFish]

Joins zijn de basis van je database, en vormen eigenlijk de structuur die je hele db bij elkaar houden, dus een goede db kan niet zonder joins! Hierbij zijn eigenlijk twee soorten joins van belang: de Inner join, en de (je raadt het...) Outer join. Er zit uiteraard verschil tussen, en wel dit:
Bij een Inner join laat je records zien die in beide gekoppelde tabellen aanwezig zijn.
Bij een Outer join laat je alle records zien uit tabel 1, en de gekoppelde records uit tabel 2.
Voorbeeldje van beide joins:
Als je een tabel Klanten hebt met 30 records, en een tabel met 15 Bestellingen van in totaal 10 verschillende klanten, dan zie je bij de Inner Join slechts 15 records. Namelijk: de 10 klanten die een bestelling hebben geplaatst.
Bij een Outer join, kies je er bijvoorbeeld voor om Alle klanten te zien (30 stuks), en alle records uit Bestellingen die een gekoppelde klant hebben (15 stuks).
Je ziet dus een resultaat van (waarschijnlijk) 35 records, waarbij je bij de klanten die nog geen bestelling hebben geplaatst, geen gegevens van de bestelling ziet, en bij de klant mèt een bestelling uiteraard wel gegevens.

Dat is de theorie (hopelijk) uit de weg geruimd
Nu jouw situatie.
Je hebt een aantal Merken, waarvoor je een eigen tabel hebt.
Je hebt een aantal Produkten, die je hebt gekoppeld aan Merk.
Dat betekent dus, dat je in de tabel Produkten alle produktgegevens hebt ingeklopt, en elk Produkt record een MerkID hebt meegegeven, zodat je weet wel Merk welke Produkten kent.
Op het moment dat je besluit om van elk Produkt bij te gaan houden welke hoeveelheden beschikbaar zijn, heb je weer een nieuwe tabel nodig: een tabel Produkt_Inhoud. Hierin maak je voor elk produkt een record met de hoeveelheid waarin die verkrijgbaar is. Uiteraard neem je in deze tabel een koppeling op naar de tabel Produkt. Als een bepaald produkt dus in 3 hoeveelheden leverbaar is, krijg je 3 records, met 3 keer een verwijzing naar hetzelfde produkt, en waarschijnlijk ook de prijs, tenzij die voor verschillende kleuren kan verschillen.
De grootste tabel die je maakt is de tabel Produkt_Inhoud_Kleur, waarin je bovenstaande stappen herhaalt, maar nu dus voor elke kleur een eigen record. Dit dan omdat ik er voor het gemak van uit ga, dat elke kleur een eigen Produktcode heeft.
In wezen is elk blikje verf dat je hebt staan, een zelfstandig item, dat je dus dienovereenkomstig dient te beschrijven in je tabellen.

Als je de constructie heel 'plat' zou maken, zou je kunnen volstaan met één tabel produkten, waar je de Merken, Kleuren en Inhoud in één keer in opslaat. Het nadeel hiervan is, dat het wat lastiger wordt om te voorkomen dat je een bepaald type verf koppelt aan een verkeerd merk.
Dat kun je wel beheersbaar houden door bovenstaand vertakking te maken.
Het basiswerk is dus wel wat meer, want je moet allerlei records maken voor de verschillende soorten gegevens die je opslaat. Maar als je het handwerk achter de rug hebt, is je db vrij degelijk!

De relaties (of joins), die je dus ten onrechte hoopt niet nodig te hebben, dienen om ervoor te zorgen, dat je geen gegevens kunt invoeren die niet in de moedertabel staan. Je voorkomt daarmee dus het invoeren van foutieve records.
Je kunt het invoeren van gegevens overigens nog wel redelijk automatiseren, door voor goede bronbestanden te zorgen. Als je bijvoorbeeld een Excel document hebt met de Produktcodes, merken, types en inhoud van de blikken, dan kun je met een paar toevoegqueries alle tabellen heel snel vullen.

 

[EGeen]

Ah, weer een helder licht, ben weer stukje verder in mijn puzzel. Volgens mij snap ik het weer een beetje meer. Zal zien of ik er nu wel uitkom. Heel erg bedankt, zou niet weten waar ik anders terecht kon met me vragen!

 

[EGeen]

Nou Ik heb heb enigzinds een beetje opgelost, met 1 grote tabel, aangezien als ik met Join functie met merk Sikkens beide (lakken & Muurverven krijg).. Doe het nu via Select Distinct.(dit is toch niet fout?) Wel wil ik het graag via meerdere tabellen laten lopen Nu heb ik een probleempje:

1 Tabel: Soort
rijen: ID en Soortnamen

2e Tabel: Totaal tabel met alles:
Zit zowiezo deze Soortnamen in een rij, opgeslagen als tekst (maar nummeriek in eigenschappen)

Als ik deze wil toevoegen met een combobox krijg ik netjes de cijfers 1 tm 10 te zien (de ID van deze opgeslagen soorten).. Wil het wel graag op deze manier doen anders lukt "select Distinct" niet. Maar omdat ik wel moet kiezen moet ik wel de teksten zien ipv de nummers... Hoe dit?

Krijg steeds meer vragen, maar vind het steeds leuker om te doen. Hopelijk geeft dit jullie hoop voor mij

 

[OctaFish]

Als ik het goed begrijp, gebruik je een keuzelijst om de soortnamen te selecteren, waarin je een ID hebt staan, en de soortnaam. Waarschijnlijk gebruik je, als de cijfers ziet i.p.v. de soortnamen, de eerste kolom als <Afhankelijke kolom>. Je zou die eigenschap op kolom 2 kunnen instellen, dan slaat hij de soortnaam op en niet de SoortID. Let er wel op, dat het veld waarin je wilt opslaan een tekstveld is, anders krijg je allerlei foutmeldingen...