Opgelost SQL code - lege string

Dit topic is als opgelost gemarkeerd

Karen#14

Gebruiker
Lid geworden
27 mrt 2024
Berichten
10
Goedemiddag,

Ik ben reeds verder met mijn database (met dank aan forum leden), maar nu wil ik een selectie (via formulier/keuzelijst) krijgen, waarbij ik gebruik maak van het geselecteerde en niet het resultaat "gebieds overstijgend" laat zien. Ik gebruik daarbij onderstaande code. Het volgende gebeurd:
  • hij laat in de MsgBox "Gebieds overstijgend" zien (deze had ik even toegevoegd voor controle),
  • maar als hij verder gaat met de code, dan plopt er een msgbox op met de vraag wat strGO is
  • als ik vervolgens "Gebieds overstijgend" intyp, dan laat hij me het gewenste resultaat zien.
Waarom onthoud hij niet wat strGO is? En hoe kan ik dit oplossen?

SQL:
Private Sub lstPerceel_Click()
Dim strSQL As String, strF As String, strGO As String

strGO = "Gebieds overstijgend"

MsgBox (strGO)
        
    strSQL = "SELECT [Percelen-Gebieden].Id, [Percelen-Gebieden].Gebied, Percelen.Perceel, [Percelen-Gebieden].Perceel_ID FROM Percelen " _
    & "INNER JOIN [Percelen-Gebieden] ON Percelen.Perceel_ID = [Percelen-Gebieden].Perceel_ID " _
    & "WHERE (([Percelen-Gebieden].Gebied)<>srtGO) AND (Percelen.Perceel_ID)=" & Me.lstPerceel.Value
              
    Me.lstGebied.Value = Null
    lstGebied.RowSource = strSQL & strF
    
End Sub

Bij voorbaat dank voor de reacties!
 
Als je werkt met een variabele (strGO), moet je de SQL-string opbouwen zoals je ook met Me.lstPerceel doet. Dus:
Code:
"WHERE (([Percelen-Gebieden].Gebied)<>'" & srtGO & "') AND (Percelen.Perceel_ID)=" & Me.lstPerceel

Omdat je met een vaste waarde werkt, heb je geen variabele nog. Dit kan dus ook:
Code:
"WHERE (([Percelen-Gebieden].Gebied)<>'Gebieds overstijgend') AND (Percelen.Perceel_ID)=" & Me.lstPerceel
 
Dank je! Ik had het al geprobeerd met vaste waarde, maar had "Gebieds overstijgend" gebruikt (aangezien ik dat ook in een query toepaste, maar dat werkte niet in de code). Het moest dus zijn: 'Gebieds overstijgend'. Nu werkt het wel! Weer wat geleerd :)
 
Als je in dit geval dubbele quotes gebruikt rond gebieds overstijgend, raakt Access in de war met de quotes rond de op te bouwen string. Vandaar.
 
Het zou fijn zijn als Peter correcte antwoorden gaf, en niet antwoorden in de geest van 'Klok en Klepel'. Waar het antwoord in #2 helaas weer een voorbeeld van is. Ongeveer weten hoe het zit, maar toch niewt echt :).

Access is een beetje lastig als het gaat om het gebruik van quotes. Enerzijds mág je in sommige gevallen een enkele quoot gebruiken, maar is het beter om dubbele quotes te gebruiken. De reden: enkele quotes zijn nogal 'gevaarlijk' als het gaat om filterwaarden die je niet zelf intypt (zoals in het voorbeeld van TS) maar uit een tabelveld haalt, zodat je geen inzicht hebt over de inhoud die je filtert. Altijd dubbele aanhalingstekens dus, zou ik voorstellen. Access raakt ook totaal niet 'in de war' als je ze correct gebruikt.
Even nog voor de zekerheid herhalend: deze string wérkt dus prima: 'Gebieds overstijgend'. En tóch zou ik het anders doen.

Even het principe uitleggen (ook voor Peter, ik heb het nog niet opgegeven dat-ie het ooit goed gaat doen ;)). Access gebruikt het dubbele aanhalingsteken om strings te bepalen. Dát heeft-ie correct uitgelegd. Wil je zoeken op een parameter, zoals jij doet met 'Gebieds overstijgend' dan is dat an sich een correcte string, maar alleen omdat er ín de string geen ' zit. Dan had Access namelijk alsnog een probleem gehad.
Neem deze filtering: ''s-Gravenhage'. Wat denk je dat dáár mee gebeurt? Zoals je ziet staan er nu twee enkele aanhalingstekens na elkaar. Voor Access staat een string altijd tussen twee tekens, dus de eerste twee tekens bepalen in dit geval de zoekstring (een lege string dus). Maar dan: kijk je verder, dan zie je aan het eind van de tekst nóg een enkel aanhalingsteken staan. Zónder tweede aanhalingsteken. En dat levert dus echt een fout op.

Die fout is alleen op te lossen door dubbele aanhalingstekens te gebruiken. Dus dit: "'s-Gravenhage". Nu staat de zoektekst tussen correcte scheidingstekens. Maar zoals Peter al aangaf: daar heeft Access óók een probleem mee, want het dubbele aanhalingsteken definieert het begin of het eind van een string, dus deze constructie
Code:
"WHERE [Percelen-Gebieden].Gebied<>"Gebieds overstijgend" AND Percelen.Perceel_ID=" & Me.lstPerceel
is inderdaad niet goed. Maar de oplossing is heel simpel, en een standaardtruc van Microsoft Windows. Als je namelijk gereserveerde tekens gebruikt, zoals het ", dan typ je dat twee keer. Access weet dan dat de aanhalingstekens onderdeel uitmaken van de complete string. De complete (en juiste) string ziet er dus zo uit:

Code:
"WHERE [Percelen-Gebieden].Gebied<>""Gebieds overstijgend"" AND Percelen.Perceel_ID=" & Me.lstPerceel

Als je jezelf deze techniek aanleert, zal je zien hoe makkelijk je het gaat toepassen, en hoe je dus nooit meer in de problemen gaat komen met tekststrings :). En ik hoop dus op het moment dat óók Peter dit gaat onthouden en toepassen. En als hij dat níet doet, dan in ieder geval vragenstellers leert wat de meest correcte oplossing is.
 
Ik had het al geprobeerd met vaste waarde, maar had "Gebieds overstijgend" gebruikt (aangezien ik dat ook in een query toepaste, maar dat werkte niet in de code). Het moest dus zijn: 'Gebieds overstijgend'.
Het zou fijn zijn als Peter correcte antwoorden gaf, en niet antwoorden in de geest van 'Klok en Klepel'. Waar het antwoord in #2 helaas weer een voorbeeld van is. Ongeveer weten hoe het zit, maar toch niewt echt :).

Access is een beetje lastig als het gaat om het gebruik van quotes. Enerzijds mág je in sommige gevallen een enkele quoot gebruiken, maar is het beter om dubbele quotes te gebruiken. De reden: enkele quotes zijn nogal 'gevaarlijk' als het gaat om filterwaarden die je niet zelf intypt (zoals in het voorbeeld van TS) maar uit een tabelveld haalt, zodat je geen inzicht hebt over de inhoud die je filtert. Altijd dubbele aanhalingstekens dus, zou ik voorstellen. Access raakt ook totaal niet 'in de war' als je ze correct gebruikt.
Even nog voor de zekerheid herhalend: deze string wérkt dus prima: 'Gebieds overstijgend'. En tóch zou ik het anders doen.

Even het principe uitleggen (ook voor Peter, ik heb het nog niet opgegeven dat-ie het ooit goed gaat doen ;)). Access gebruikt het dubbele aanhalingsteken om strings te bepalen. Dát heeft-ie correct uitgelegd. Wil je zoeken op een parameter, zoals jij doet met 'Gebieds overstijgend' dan is dat an sich een correcte string, maar alleen omdat er ín de string geen ' zit. Dan had Access namelijk alsnog een probleem gehad.
Neem deze filtering: ''s-Gravenhage'. Wat denk je dat dáár mee gebeurt? Zoals je ziet staan er nu twee enkele aanhalingstekens na elkaar. Voor Access staat een string altijd tussen twee tekens, dus de eerste twee tekens bepalen in dit geval de zoekstring (een lege string dus). Maar dan: kijk je verder, dan zie je aan het eind van de tekst nóg een enkel aanhalingsteken staan. Zónder tweede aanhalingsteken. En dat levert dus echt een fout op.

Die fout is alleen op te lossen door dubbele aanhalingstekens te gebruiken. Dus dit: "'s-Gravenhage". Nu staat de zoektekst tussen correcte scheidingstekens. Maar zoals Peter al aangaf: daar heeft Access óók een probleem mee, want het dubbele aanhalingsteken definieert het begin of het eind van een string, dus deze constructie
Code:
"WHERE [Percelen-Gebieden].Gebied<>"Gebieds overstijgend" AND Percelen.Perceel_ID=" & Me.lstPerceel
is inderdaad niet goed. Maar de oplossing is heel simpel, en een standaardtruc van Microsoft Windows. Als je namelijk gereserveerde tekens gebruikt, zoals het ", dan typ je dat twee keer. Access weet dan dat de aanhalingstekens onderdeel uitmaken van de complete string. De complete (en juiste) string ziet er dus zo uit:

Code:
"WHERE [Percelen-Gebieden].Gebied<>""Gebieds overstijgend"" AND Percelen.Perceel_ID=" & Me.lstPerceel

Als je jezelf deze techniek aanleert, zal je zien hoe makkelijk je het gaat toepassen, en hoe je dus nooit meer in de problemen gaat komen met tekststrings :). En ik hoop dus op het moment dat óók Peter dit gaat onthouden en toepassen. En als hij dat níet doet, dan in ieder geval vragenstellers leert wat de meest correcte oplossing is.

En Karen: de reden dat het in een query wél goed werkt, is natuurlijk omdat een query SQL is, en geen programmeertaal. Als je weet hoe het zit, is het ook makkelijker te onthouden. Ik geneer me altijd een beetje als helpers onvolledige antwoorden geven, vandaar dat ik toch maar even inspring ;).
 
He OctaFish,

Dank je voor je nadere uitleg. Ik heb het aangepast!

Vriendelijke groeten,

Karen
 
@Karen#14 Volgens mij zit het oorspronkelijke probleem in het feit dat je een tikfout maakte in je code.
Je definieert strGO als string, maar je gebruikt srtGO in je query.
Uiteraard wordt srtGO niet herkend, aangezien die nooit is gedefinieerd.
 
Dat was maar één aspect van de fout. De belangrijkste fout was dat een tekststring ook als tekst moet worden behandeld. De variabele is geen numerieke waarde, dus [Percelen-Gebieden].Gebied)<>strGO was pertinent ook fout geweest. Zoals hierboven ook al is uitgelegd.

Kleine tip: als je een variabele definieert met daarin hoofdletters, roep hem dan aan met kleine letters. Access zal dan de 'foutieve' aanroep automatisch verbeteren.
Dus als dit je variabele is:
Code:
Dim strGO as String
En je typt dit:
Code:
[Percelen-Gebieden].Gebied)<>srtgo
Dan blijft de variabele in kleine letters staan. Je weet dan dat je een typefout hebt gemaakt. Typ je dit:
Code:
[Percelen-Gebieden].Gebied)<>strgo
Dan is het resultaat als je doortypt:
Code:
[Percelen-Gebieden].Gebied)<>strGO
Access heeft de tekst aangepast aan de declaratie. Je weet dan dat je géén typefout hebt gemaakt.

Dat is één van de redenen dat ik wel degelijk zoveel mogelijk variabelen declareer (in tegenstelling tot wat andere helpers hier zeggen, namelijk dat het onzinnig is om variabelen te declareren). Je hebt dan een visuele controle op de juistheid van de syntax.
 
Tja, OctaFish, ik ken de opbouw van de databank niet, dus baseerde ik mij enkel op de gegeven code.
Handige tip die je daar geeft.
Ik gebruik Access ook niet, enkel een zelf geprogrammeerde frontend met mySQL of dergelijke als backend.
 
Terug
Bovenaan Onderaan