Query geeft geen resultaat

Status
Niet open voor verdere reacties.
W

Wocky

Gebruiker
Lid geworden
22 feb 2014
Berichten
192
Beste,

Ik ben een baby-groentje in Acces.
Ik heb getracht een zeer eenvoudige mini-database op te zetten van 2 types artikelen.
Zie bijlage.

Er zit een Query in genaamd "qry_01_PrijslijstTOTArtikels"
... ik heb de extentie gewijzigd van accdb naar txt... aangezien ik het bestand niet geupload kreeg.

Kan iemand mij uitleggen waarom ik geen resultaten te zien krijg in deze Query?

NB:
Ik heb wel deze video-cursus verorberd vorige week.
Dus normaal zou ik wel de basis-concepten moeten begrijpen... maar blijkbaar niet dus.
https://www.youtube.com/playlist?list=PLoyECfvEFOjYqifYG9xBEcJkdh395-bjx


Alvast bedankt.
Wocky.
 

Bijlagen

  • Calculatie_Artikelen_1.txt
    796 KB · Weergaven: 13
De relaties tussen de tabellen kloppen niet. De benaming van de tabellen vind ik niet echt logisch waardoor het een grote zoektocht wordt van wat je als resultaat verwacht. Ook is het niet handig om in elke tabel het ID veld ID te noemen. Geef bv in de tabel met artikelen het Id de naam ArtikelID.
 
Leg eens uit wat de bedoeling is van je database; ik snap 'm niet. Ik zie geen problemen met je relaties, in tegenstelling tot vena, maar logisch is anders. Om te beginnen: twee tabellen voor dezelfde entiteit (artikelen)? Niet logisch. Een derde tabel TotArtikels? in mijn ogen totaal overbodig. Wat moet je daar mee?
 
Mij lijkt het dat en een relatie tussen een ID in alle tabellen autonummering met een tekstveld in een een andere tabel niet echt tot een nuttig resultaat kan leiden. Maar ik zie dat mijn conclusie iets te snel was. ArtikelNaam impliceert een tekstveld maar is numeriek. En de weergave is tekst? Wie heeft dat nu weer verzonnen?:d
 

Bijlagen

  • Knipsel.JPG
    Knipsel.JPG
    52,1 KB · Weergaven: 24
  • Knipsel2.JPG
    Knipsel2.JPG
    19,4 KB · Weergaven: 21
  • Knipsel3.JPG
    Knipsel3.JPG
    20,8 KB · Weergaven: 22
VenA zei:
En de weergave is tekst? Wie heeft dat nu weer verzonnen?
Klik om te vergroten...
Wat bedoel je daar mee? Ik zie alleen dat TS in tabellen keuzelijsten heeft gebruikt. (TS: als je mijn antwoorden leest, dan weet je dat ik dat NOOIT doe. Bedenk maar eens waarom dat in mijn ogen heel erg fout is...). En in die velden zie je teksten terug, niet het ID veld. Die teksten zijn inderdaad.... tekst :).
 
Je kan in de plaatjes overduidelijk zien wat ik bedoel. Ontwerpweergave vs tabelweergave. Vervolgens leg je uit je wat ik bedoel?
 
Ik vermoed dat je nog niet helemaal snapt hoe Keuzelijsten in een tabel werken. Dat heeft niets met numeriek veld en tekstweergave te maken. Zeker niet met iemand die iets verzonnen heeft. Je leidt alleen maar af van het echte probleem :).
 
Beste,

Het idee is dat ik een prijs bepaal van een "TotaalProduct" samengesteld uit verschillende SubArtikelen.
... in het voorbeeld zijn er 2 SubArtikelen
... elk met een prijs, gecreëerd vanuit speciefieke eigenschappen.

We hebben in het voorbeeld dus 2 Typen SubArtikelen.
... Type A = een prijs gebaseerd op de eigenschap Oppervlakte
... Type B = een prijs gebaseerd op de eigenschap Volume.


Een ander voorbeeld is
- Totaalproduct = Stoel
- SubArtikel Type A = Zitvlak ... bvb met prijzen gebaseerd op m² Oppervlakte
- SubArtikel Type B = Poot ... bvb met prijzen gebaseerd op m³ Volume


Het uiteindelijke doel is dat ik een DataBase wil opbouwen, waar ik TotaalProducten ga samenstellen
... op basis van pakweg 50 verschillende mogelijkheden aan "Type" SubArtikelen.

In het voorbeeld zijn het er dus slechts 2.. Type A & B
... maar in realiteit gaat het dus over veel meer.


Maar mijn vraag is... hoe komt het dat ik geen resultaat krijg in die Query?
(QueryNaam is aangepast naar "qry_01_Prijslijst_SAMENGESTELDEProducten")
Ik dacht dat het misschien lag aan het feit dat ik .. in de opzoekvelden, de tekst-waarde inlas, ipv het ID nummer
... heb ik aangepast, maar zonder resultaat.
... Bij de link aan de prijslijst werkt het trouwens wél, ik lees in de SubArtikels een tekstwaarde vanuit de prijslijst in... en in de Query "Prijslijst_SUBArtikels" komt de juiste prijs wel naar boven.


In bijlage een nieuwe versie van het bestand.
Ik heb de namen van tabellen wat aangepast...
... betreft de nummering in de tabelnaam... daarvan heb ik het idee de nummering te gebruiken.. om de tabellen te kunnen sorteren op nummer.. ipf op alfphabet.
... ik stel voor daar niet te hard op te focussen... het kan zijn dat ik nog wijzig.


Groeten Wocky.
 

Bijlagen

  • Calculatie_Artikelen_V2.txt
    792 KB · Weergaven: 10
Of ligt het aan het feit dat er geen Primary-Key bestaat in de gelinkte Queries
- qry_01_Prijslijst_SUBArtikels_OPPERVLAKTE
- qry_01_Prijslijst_SUBArtikels_VOLUME
?

Wat zou betekenen dat je geen Join-Query kan maken op basis van een andere Query als brondata?

Bekijk bijlage 358208
 
Ik ben er achter dat het komt, omdat ik in de tabel "SamengesteldeProducten"
... geen waarde invul voor ProductType A of B

Als ik Beide Typen invul, krijg ik wel een resultaat.
... aangezien er geen "null" artikelen bestaan in de tabellen van Type A en B

... dan is de vraag.. hoe lost ik dit op... of wat doe ik fout in mijn linken..?
 
Stop eens met die losse tabellen. Als je een Product wilt samenstellen uit verschillende losse onderdelen, dan volstaat één tabel met (gezamenlijke) eigenschappen. Een eigenschap kan zijn: 2D of 3D, en de eenheid m2 of m3. Maakt voor het artikel niet uit, dus één tabel. Jij hebt nu al twee tabellen; dat gaan er dan 50 worden? Ikmhebmfaa% maar één woord voor: bezopen. Niet te hanteren ook in een database.
Tabellen bouw je op basis van Entiteiten die dezelfde eigenschappen hebben. Artikelen hebben doorgaans een hoop dezelfde eigenschappen. Die eigenschappen leg je vast in velden, en in één record beschrijf je dus één object door de eigenschappen ervan vast te leggen.

Een product is dan dus niets meer dan een verzameling artikelen die samen het product bepalen. Gebruik daarvoor niet meer, maar ook niet minder dan twee tabellen. Die dan een één-op-veel relatie hebben. In het hoofdformulier Product vul je in een subformulier dan de artikelen in, en de aantallen.
 
Als ik straks alles in 1 tabel plaats.. en ook nog prijzen per subartikel bereken... dan heb ik een tabel van 200 kolommen breed.
Dat kan toch ook niet de bedoeling zijn?

Daarom dat ik net denk aan 1 tabel, waar ik via ID's subartikels inlaad.
Zo heb ik dan Per type subartikel inderdaad 1 tabel.
En 1 Producttabel, waar subartikels zijn ingeplugd.

Een DataBase dient toch net om ge makkelijk relaties te leggen tussen tabellen?
Anders kan ik net zo goed in Excel een Tabel maken.
 
Ik heb nergens gezegd dat je één tabel moet maken. Wel moet je van de (sub)artikelen alle gezamelijke aspecten in één tabel zetten. Dát zijn de elementen die je ook terug wilt zien als je een product gaat samenstellen. Als er van artikelen eigenschappen (noemen we attributen) zijn die specifiek zijn voor dat ene artikel, dan maak je dáár aparte tabellen voor. Bij voorkeur ook weer tabellen waarin je eigenschappen van meerdere artikelen kan opslaan als dat mogelijk is. Maar begin eens met je tabellen te normaliseren, dat scheelt al een hele hoop.
En een laatste tip: databases kun je inderdaad niet rechtstreeks posten, maar wél als je ze eerst zipt. En dan worden ze nog een stuk kleiner ook.
 
Ok bedankt,

Ik ga ermee aan de slag.
Nu... betreft de Query in de post...
... de oorzaak van het niet verschijnen van records zat hem in het feit, dat ik geen waarde ingevuld had in de koppeltabel.
Nu heb ik null-subartikelen gemaakt, om iets te kunnen invullen.

Is dit de juiste manier van werken voor dergelijke zaken?
Of wordt dit normaal anders opgelost?

Zie afbeeldingen.

mvg,
Wocky

Knipsel - 1.jpgKnipsel - 2.jpg
 

Bijlagen

  • Calculatie_Artikelen_V5.zip
    48,1 KB · Weergaven: 13
Kijk nou eens naar je eigen plaatje, en zoek de verschillen tussen de twee queries die je hebt gekoppeld. Die zijn er niet, op het veld Diepte na. Nogmaals: maak er één tabel van, met daarin alle velden die je altijd nodig hebt. Eigenlijk moet je dus een tabel hebben waarmee je alle eigenschappen van één artikel kan vastleggen. Dat wil niet zeggen dat je ook alle attributen altijd moet invullen. JE vult ze uiteraard alleen in als dat nodig is. Bij een 2D artikel vul je dus géén diepte in, bij een 3D artikel wél. (En gebruik je eventueel een regel die controleert of dat ook daadwerkelijk correct gebeurt).
Vergelijk het met een NAW tabel: daarin leg je namen vast van contactpersonen. Die hebben een voornaam en een achternaam, en soms een tussenvoegsel. Dat laatste vul je alleen in als dat nodig is.

Eérst je database goed ontwerpen, dán pas nadenken over de volgende stappen. Ik heb zwaar het gevoel dat je maar een beetje lukraak begonnen bent, zonder goed uitgedacht Functioneel Ontwerp. En daar kan je in Excel en in Word nog wel mee wegkomen, maar niet in een database.
 
Ik ben inderdaad aan het experimenteren...
... moest dat nog niet duidelijk zijn.

Dat gaat met vallen en opstaan.
Ik zeg niet dat ik die 2 tabellen straks niet in 1 zet.

Mijn vraag is, wat als ik straks in een situatie kom, waar ik wél 2 tabellen moet koppelen.. wat dan?
Je zegt zelf .. "ik heb niet gezegd alles in 1 tabel".. maar eigenlijk zeg je het wel he.

Wat doe je met productspecifieke eigenschappen.. die je niet ook in dezelfde tabel wil?
Dat is toch dezelfde situatie als deze dan?

Anders heb ik straks een tabel met +200 kolommen.
 
Dat was echt wel duidelijk. Jammer genoeg is Access niet het beste programma om te experimenteren. Ik heb laatst een hersenoperatie gehad van een jonge student die zonder opleiding aan het experimenteren was. Nu denk ik dat ons land wordt geleid door mensen die weten wat ze aan het doen zijn..... Ik heb uiteraard mijn geld terug gevraagd :).

Ja, wat ik zeg is: zet alle entiteiten (objecten) die dezelfde structuur hebben bij elkaar in één tabel. Hang/koppel daar eventueel een (aantal) tabel(len) aan met aanvullende deelgegevens als dat nodig is. Maar een grasmaaier is in essentie niets anders als een auto: een object dat is samengesteld uit verschillende onderdelen. En die onderdelen zijn in essentie óók hetzelfde opgebouwd. Zorg ervoor dat die structuur klopt, voordat je verder gaat. Je gaat anders in hele grote problemen komen met je database. En daar kom je dan zelf echt niet meer uit, en dan kost het je veel meer (en tijd) om dat te herstellen. Meestal is het advies: overnieuw beginnen. Dus vandaar dat ik dat nú al (en geheel gratis ;)) geef.

En je eindigt echt niet met één tabel met 200 velden. En zelfs als dat wél het geval is: is altijd nog te prefereren boven jouw opzet.
 
Dat zeg ik :). Maar dan in het Nederlands, want dat is toch zo'n mooie taal....
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan