VBA DCount SQL query resultaat

Status
Niet open voor verdere reacties.

Floor E

Gebruiker
Lid geworden
22 dec 2007
Berichten
362
Ik wil af van de query's en alle query's omzetten in SQL in de VBA code. Ik heb het idee dat Access dan veel sneller de query's verwerkt (ik heb er nogal wat).

Het gaat al aardig de goede kant op maar iets, wat naar mijn mening niet al te moeilijk moet zijn, krijg ik niet voor elkaar. Indien ik in Access met query's werk ziet de code er zo uit:
(even versimpelde weergave: )
Code:
    If (DCount("[ID]", "Query1") > 10) Then
                MsgBox "Kiekeboe", vbOKOnly, ""
                End If

Echter, ik wil af van de Query1 en er SQL code voor gebruiken. Ik heb geprobeerd om de SQL code op de plaats van Query1, tevens geprobeerd om de query in een array te plaatsen maar dat werkte ook niet lekker.
Wie kan me op weg helpen?
 
Laatst bewerkt:
Daarvoor zul je je queries om moeten bouwen naar VBA.

a) juist queries in VBA (statische queries) zijn langzamer, niet sneller
b) queries zelf (dynamische queries) zijn makkelijker te onderhouden (en sneller)
c) aggregatiefunkties zoals DCount zijn trager

Groet,

Tardis
 
Laatst bewerkt:
Tardis, bedankt voor je reactie.
Persoonlijk ervaar juist het tegenovergestelde, plus het grote voordeel dat je de query's compleet dynamisch maakt. Resultaten uit voorgaande query's kan je als variabele gebruiken in de volgende RST. Zie het als een soort klok waarbij je een grote wijzer, kleine wijzer en een seconde wijzer hebt. Dit was voorheen erg traag terwijl hij er nu overheen vliegt.

Ik heb de query in VBA geplaatst dmv een strSql en vervolgens een DoCmd.RunSQL StrSql

Dit werkt goed, ik heb alleen een probleem met de analyse. En zoals gezegd probeer ik alles in VBA te krijgen. Ook goed voor het leer moment..
 
Dat je het tegenovergestelde ervaart kan in jouw specifieke geval kloppen.
Blijft het feit staan dat queries an sich sneller zijn dan SQL geschreven in VBA.
Op de achtergrond wordt daar namelijk een soort "plan" van gemaakt, zodat een query als die een volgende keer gestart wordt op de meest efficient wijze (in dit geval gemeten naar Microsoft maatstaven) gedraaid wordt.
Met SQL geschreven in VBA gebeurt dat niet.

Groet,

Tardis
 
Kijk, dat is interessant. Als ik daar meer informatie over wil vinden, onder welke noemen/zoekterm kan ik dan het beste gaan zoeken want dit is echt nieuw voor me?

k hoop dat binnenkort het laatste blok van mijn VBA cursus start (we moeten met minimaal 7 man zijn wil die kunnen starten). Daar wordt dit hopelijk behandeld.

Als ik het goed samenvat en begrijp dan kan dus het beste,waar mogelijk, met de standaard query's werken. Nadeel is wel dat je beperkt bent met het aantal tabellen en de lengte van je SQLcode in de standaard query.

Nogmaals bedankt voor je info.
 
Laatst bewerkt:
Nadeel is wel dat je beperkt bent met het aantal tabellen en de lengte van je SQLcode in de standaard query
.

Ten opzichte van VBA bedoel je, dan zit je er pertinent naast.
Nadelen zitten eerder in VBA, bedenk bijvoorbeeld dat een string maar een maximaal aantal tekens kan bevatten.

En over onderhoud en beheer heb ik het al eerder gehad ;)
Kan me vergissen maar zoek je de voordelen niet waar ze niet te vinden zijn?

Mbt je vraag, heb dat ooit ergens gelezen, geen idee waar, google eens op

Jet Engine plan (maken van een "plan" wordt dacht ik door de Jet Engine geregeld)

Groet,

Tadis
 
Sql

Je zou deze uit kunnen schrijven naar sql soor de telling in je query te verwerken. Je krijgt dan iets als
Code:
set rs=currentdb.openrecordset("SELECT COUNT(ID) AS Maxnr FROM tabel1")
if rs!Maxnr>10 then.....
 
Ten opzichte van VBA bedoel je, dan zit je er pertinent naast.
Nadelen zitten eerder in VBA, bedenk bijvoorbeeld dat een string maar een maximaal aantal tekens kan bevatten.

Mooi punt voor discussie :) .
Dit is voor mij juist de rede geweest om over te stappen. Ik had het probleem dat ik tegen de limiet van de query aanliep (zowel in de visuele editor als in het gedeelte om de SQL te programmeren). Maximaal aantal velden en maximale lengte aan SQLcode. Viel ook niet aan te passen (ik kon het niet vinden). Nadat ik de SQLcode had overgezet in VBA kon ik weer volop uitbreiden.

Ik had van de cursus begeleider de tip gekregen om juist alle code te programmeren. Dit houdt de database compact en makkelijk aan te passen. Ik werk veel met modules namelijk. Hoewel ik volmondig met je eens ben dat ik liever met de visuele editor werk dan code kloppen maar de mogelijkheden met code kloppen zijn naar mijn mening veel uitgebreider.

Zie ook deze discussielijn en vooral de reactie van Bartuls:
http://www.helpmij.nl/forum/showthread.php?t=319818&page=2

Allebei harstikke bedankt voor jullie reacties! :thumb:
 
Als je zowiezo met VBA werkt, en je kunt zo programmeren dat code herbruikbaar is, is dat inderdaad wel zo handig.
Voor de rest kan ik de gedachtengang van jou en je cursusleider niet plaatsen.

Zo lang het maar voor jou werkt :D

Groet,

Tardis
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan