🚀 go-pugleaf

Passero wrote:
> 
> Telkens wanneer ik onderstaande query wil uitvoeren loopt mijn pc vast. Ik
> heb al geprobeerd in VB6 door het in de recordsource te zetten van een ADODC
> en in een DB programma van mysql voor query's. Mijn computer loopt gewoon
> vast en ik kan niet anders doen dan een reset. Nogtans klopt de query want
> enkel als ik de access equivalant van de DB gebruik en de query in access
> uitvoer lukt het. In mysql met een mysql db niet dus. Weet iemand raad?

Weet je zeker dat je computer "vast loopt", of is hij gewoon erg lang
bezig met het uitrekenen van de resultaten? Je doet een join over drie
tabellen. Als je geen indices hebt, kan dat errug lang duren.

Dus: welke indices heb je staan? Indices op de PKs is bijna
verplicht. Indices op de FKs kan in een aantal gevallen ook
helpen, afhankelijk van hoe de aanpak van je query is.

Verder zou je een "SELECT COUNT(1) FROM ..." kunnen doen om te kijken
hoeveel resultaten je hebt. En dan geen DISTINCT of ORDER BY, want dat
kost alleen maar extra tijd. Bij grotere aantallen ligt het voor de hand
dat je query een boel tijd nodig heeft.

> Hier de query:
> 
> SELECT DISTINCTROW REPERTORIUM.ZAAKNR, REPERTORIUM.HOEDANIGHEID,
> AKTEN.REPNR, AKTEN.AARD, AKTEN.ONDERWERP, KLANTEN.FAMNAAM, KLANTEN.VOORNAAM,
> KLANTEN.VOLGNR_AKTE, KLANTEN.ALLEEN_OF_SAMEN FROM (AKTEN INNER JOIN
> REPERTORIUM ON AKTEN.ZAAKNR = REPERTORIUM.ZAAKNR) INNER JOIN KLANTEN ON
> REPERTORIUM.KLANTNR = KLANTEN.KLANTNR ORDER BY REPERTORIUM.ZAAKNR,
> KLANTEN.VOLGNR_AKTE

Ziet er normaal uit. Is die DISTINCTROW echt nodig?

Je zou de inner joins impliciet kunnen maken:
FROM AKTEN, REPERTORIUM, KLANTEN
WHERE AKTEN.ZAAKNR = REPERTORIUM.ZAAKNR
  AND REPERTORIUM.KLANTNR = KLANTEN.KLANTNR
Dat is waarschijnlijk makkelijker te optimaliseren. Maar ik denk niet
dat het daaraan ligt.

Sjoerd Schreuder

"Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> schreef in bericht
news:3F7ADCF6.5459EB8E@wanadoo.nl...

>
> Weet je zeker dat je computer "vast loopt", of is hij gewoon erg lang
> bezig met het uitrekenen van de resultaten? Je doet een join over drie
> tabellen. Als je geen indices hebt, kan dat errug lang duren.
>
> Dus: welke indices heb je staan? Indices op de PKs is bijna
> verplicht. Indices op de FKs kan in een aantal gevallen ook
> helpen, afhankelijk van hoe de aanpak van je query is.
>
> Verder zou je een "SELECT COUNT(1) FROM ..." kunnen doen om te kijken
> hoeveel resultaten je hebt. En dan geen DISTINCT of ORDER BY, want dat
> kost alleen maar extra tijd. Bij grotere aantallen ligt het voor de hand
> dat je query een boel tijd nodig heeft.
>

Hoe komt het dan dat access er niet lang over doet, hij doet het direct?

Indices gemaakt (die waren er dus nog niet) en nu gaat het heel vlot. Moet
zelf niet meer wachten.
Bedankt!

On Wed, 01 Oct 2003 16:30:45 +0200, Passero wrote:


> "Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> schreef in bericht
> news:3F7ADCF6.5459EB8E@wanadoo.nl...
> 
> 
>> Weet je zeker dat je computer "vast loopt", of is hij gewoon erg lang
>> bezig met het uitrekenen van de resultaten? Je doet een join over drie
>> tabellen. Als je geen indices hebt, kan dat errug lang duren.
>>
>> Dus: welke indices heb je staan? Indices op de PKs is bijna verplicht.
>> Indices op de FKs kan in een aantal gevallen ook helpen, afhankelijk
>> van hoe de aanpak van je query is.
>>
>> Verder zou je een "SELECT COUNT(1) FROM ..." kunnen doen om te kijken
>> hoeveel resultaten je hebt. En dan geen DISTINCT of ORDER BY, want dat
>> kost alleen maar extra tijd. Bij grotere aantallen ligt het voor de
>> hand dat je query een boel tijd nodig heeft.
>>
>>
> Hoe komt het dan dat access er niet lang over doet, hij doet het
direct?

Wilde gok: misschien heb je in Access wel de nodige indexen, maar in
Mysql niet?

-- 
"Codito ergo sum"
Roel Schroeven