SGQ van query of row source omzetten naar VBA

wou dit verwijderen maar gaat niet?

reneemettrie zei:

Wat zijn nu de algemene regels voor de SQL binnen VBA?
geen komma op het einde
tabelnaam moet er niet overal bijstaan
niet al die haakjes

Klik om te vergroten...

Deze 'regels' zijn mij onbekend, en die gelden m.i. ook helemaal niet. Je mág een puntkomma op het eind zetten (een komma natuurlijk niet, maar dat mag in de SQL ook niet) , een tabelnaam is volgens mij wel degelijk verplicht (zeker in een SELECT) en haakjes mag je net zoveel gebruiken als je wilt. Dat Access er zelf idioot veel neerpent, wil overigens niet zeggen dat jij dat ook moet doen .
Persoonlijk zou ik zoveel mogelijk WHERE gebruiken en niet HAVING, maar zelfs dat mag de functionaliteit van de query niet aantasten.

Er zijn twee mogelijkheden, afhankelijk van of je keuzelijst Landen een getal of tekst teruggeeft. Jouw voorbeeld code (France) suggereert tekst, maar dat zou dan betekenen dat je het sleutelveld van de Landentabel niet gebruikt. Maar het kan... Hier dus de twee varianten, de eerste op basis van een getal, de tweede op basis van een tekst.



Ik gebruik altijd de <Bij klikken> gebeurtenis, zelden de <Na bijwerken>. Waarom? Je klikt op een waarde, dus dat werkt sneller. Je hoeft dan de keuzelijst niet te verlaten.

Bedankt voor de uitleg.
Had het bericht ondertussen wel proberen te verwijderen, want had mijn fout gezien (land niet bij de having gezet)
Die concatenatie met inhoud van combobox voor het land was ondertussen ook OK
Having ipv where omdat ik geen aparte landentabel heb, en uit ledentabel moet je dus "group by" doen.

Toch nog een vraagje: beide lijsten zijn not limit to list.
Als je een nieuw land invult gebruik ik de code docmd.requery cbo_Land
Maar als je een nieuwe stad invult moet de row source daarvan ook aangepast worden. Doe je dat met zelfde commando als hierboven "cbo_stad. set rowsource...." of kan dat korter?

En wanneer gebruik je beter after update dan click?

Laatste vraag: geen idee . Ja, bij tekstvakken. Niet bij keuzelijsten. Als je geen aparte landentabel hebt kun je nog steeds de WHERE gebruiken en dus niet de HAVING. WHERE in combinatie met DISTINCT werkt voor mij beter. Dus ik hou het bij mijn werkwijze .
Als je geen aparte landen/steden tabel hebt, gebruik je m.i. een slecht genormaliseerde tabel, dus dat zou ik zeker heroverwegen. Je kunt dan ook de gebeurtenis <Bij niet in lijst> gebruiken om nieuwe landen en steden toe te voegen.

Ik val in herhaling
Voorbeelden zijn niet voor eindgebruikers, maar worden gebruikt voor cursussen, van basis Access tot intro VBA. Echte basis, niet het niveau van jouw cursus "voor Beginners"
In een basiscursus kan je moeilijk "NotInList" beginnen programmeren. En in de VBA Intro is het een voorbeeld voor docmd.requery en komt NotInlist aan bod bij DAO, als daar tijd voor is.
In een basiscursus vertel ik trouwens dat je met een aparte landentabel zou kunnen werken, maar dat je dan VBA nodig hebt om nieuwe landen toe te voegen.

Ik vind dat je in een basis cursus in ieder geval de basisprincipes van een goede database moet behandelen en uitleggen. Normaliseren is daarvan een belangrijk onderdeel, en dataredundantie stimuleren (en de meer dan kleine kans op foute invoer) lijkt mij niet de juiste weg. Als een gebruiker niet toe is aan VBA oplossingen, dan leer ik hem/haar om dan maar eerst handmatig een nieuw land toe te voegen en dan verder te gaan. Alles beter dan iemand aan leren om verkeerde databases te maken.

Relaties en referentiële integriteit vormen wel een belangrijk onderdeel van een basiscursus hoor.
Maar waar houdt dit op? Moet je dan voor alle landen, steden, straten een aparte tabel gaan maken?

Lijkt mij niet; één landentabel, één stedentabel (met LandID). één stratentabel (met PlaatsID). Al hangt het ook weer af van hoeveel landen en plaatsen je hebt natuurlijk.

De hele wereld
Maar een verkeerd land invullen wordt vermeden door een keuzelijst van de reeds ingevoerde landen aan te bieden.
Ik heb zelf een voorbeeld uitgewerkt met een leden-, activiteiten- en inschrijvingentabel. Vele opleiders (en boeken) gebruiken de Noordenwindtabel van MS. Daar eens gaan kijken: geen landentabel, en bij klantentabel kan je om het even welk land invullen.
Maar akkoord, als je met één land werkt kan je beter een tabel met steden en postcodes gebruiken. Doe ik voor mijn persoonlijke DB, als het gaat om mensen uit België.

Noordenwind is m.i. meer een voorbeeld van hoe je kunt programmeren in Access dan een voorbeeld van hoe een goede database er uit hoort te zien. Jammer genoeg snappen veel mensen dat niet, en die denken dat ze met NOordenwind een prima voorbeeldje hebben van hoe een database er uit zou moeten zien. En er zijn zelfs genoeg mensen die hem zo in gebruik nemen voor zichzelf. Geeft niks, dan heb ik ook weer werk .