[VB6] Waarom krijg ik telkens timeouts via ADO *

[Verwijderd]

Ik zit met een raar probleem te kijken.
Vanuit een VB applicatie roep ik via ADO een database aan.
So far so good, echter bij een bepaald overzicht krijg ik een timeout.
Egaal wat ik doe, resultaten komen er niet. (overdag dan, als er veel gebruikers in het systeem zitten).
De uitgevoerde query wordt ter controle ook in het debug venster neer gezet.
Als ik van daaruit de uitgevoerde query nu in de QUERY analyzer paste, en 'm daar laat uitvoeren, heb ik in een seconde of 10 resultaat. OOK overdag met alle gebruikers.

Relevante code:

Set Conn = CreateObject("ADODB.Connection")
Conn.ConnectionString = "uid=sa;pwd=<PWD>;server=ENLIGHTMENT;driver={SQL Server};database=GLOBE202;"
Set RS = Conn.Execute(Query)

Gebruikte ADO lib:

msado15.dll (ADO 2.6)

De vraag is dus eigenlijk;

Waarom kan de query analyzer ZONDER timeout de gegevens opvragen in een paar seconde
en kan ik met een timeout van 900 seconden nog geen results krijgen?

Andere queries binnen mijn tool werken prima, alleen bij deze query treed het probleem op.
De Query kan het niet aan liggen, immers de Query analyzer komt keurig met de goede resultaten, op korte tijd. Daarnaast werkt de query op rustige moment ook.

[ Voor 4% gewijzigd door Verwijderd op 24-05-2005 15:21 ]

[faabman]

wat is je query??

[Verwijderd]

Daar ga je weinig aan hebben; maar als je 'm wil weten:

select itemcode,description,
(select count(esr_aantal) as verkochte_items from orsrg where artcode=itemcode and afldat BETWEEN '2005-04-01 00:00:00.000' AND '2005-05-09 00:00:00.000') as omzet,
(select count (description) from absences where type=99 and absences.itemcode=items.itemcode AND syscreated BETWEEN '2005-04-01 00:00:00.000' AND '2005-05-09 00:00:00.000') as Klachten,(select count (description) from absences where type=84 and absences.itemcode=items.itemcode AND syscreated BETWEEN '2005-04-01 00:00:00.000' AND '2005-05-09 00:00:00.000') as RTVs,UserYesNo_04 as MDD,(CASE WHEN (select count(esr_aantal)
from orsrg where artcode=itemcode and afldat BETWEEN '2005-04-01 00:00:00.000' AND '2005-05-09 00:00:00.000' )>0 THEN (100/(select count(esr_aantal) from orsrg where afldat BETWEEN '2005-04-01 00:00:00.000' AND '2005-05-09 00:00:00.000' and artcode=itemcode)*(select count (description) from absences where type=99 and syscreated BETWEEN '2005-04-01 00:00:00.000' AND '2005-05-09 00:00:00.000'
and absences.itemcode=items.itemcode)) ELSE -1 END) as percentage From items order by MDD desc,klachten desc,RTVs desc

had je gewaarschuwd ;-)

[ Voor 33% gewijzigd door Verwijderd op 24-05-2005 16:03 ]

[bigbeng]

Waarom gebruik je createobject en niet gewoon een reference naar je ADO lib toevoegen en dan met

Visual Basic:

Dim conn As New ADODB.Connection

?

[Verwijderd]

Is wat makkelijker qua coden in dit geval.
Ik heb die connectie als PUBLIC staan, dan is het wat makkelijker om 'm ter plekke aan te maken.

Maar hij is omgezet. Nu is de code dus zoals jij 'm zegt.
(die reference was er overigens al)

[faabman]

Waar open je eigenlijk de verbinding met je database??

[ Voor 10% gewijzigd door faabman op 24-05-2005 16:29 ]

[Verwijderd]

Verwijderd schreef op dinsdag 24 mei 2005 @ 16:01:
Daar ga je weinig aan hebben; maar als je 'm wil weten:

code:

select itemcode,description,
(select count(esr_aantal) as verkochte_items 
from orsrg 
where artcode=itemcode and afldat BETWEEN '2005-04-01 00:00:00.000' AND '2005-05-09 00:00:00.000') as omzet,

had je gewaarschuwd ;-)

Is dat wel de goede manier om op tijdvelden te zoeken? Er staat me iets van bij dat die tussen # moeten...

[ Voor 52% gewijzigd door Verwijderd op 24-05-2005 16:31 ]

[henkleerssen]

Lekkere query zeg.. ik ben met faabman..

[Verwijderd]

DAJAN -> Nee, dit zijn geen tijd velden, gewoon char velden waar Exact rotzooi in plaatst die als tijd stempel dienen.


Ja dat was ik er vergeten bij te plaatsen, er zat nog een conn.open tussen :-)

Maar ik zal zo de nieuwe code even pasten. Hij accepteert nu ineens mijn command timeout van 2000 :-) Kortom, mijn VB hangt :-)

[ Voor 23% gewijzigd door Verwijderd op 24-05-2005 16:34 ]

[henkleerssen]

Verwijderd schreef op dinsdag 24 mei 2005 @ 16:31:
[...]


Is dat wel de goede manier om op tijdvelden te zoeken? Er staat me iets van bij dat die tussen # moeten...

Hoeft niet per se.. welke db gebruik je eigenlijk?

[henkleerssen]

Verwijderd schreef op dinsdag 24 mei 2005 @ 16:32:
Ja dat was ik er vergeten bij te plaatsen, er zat nog een conn.open tussen :-)

Maar ik zal zo de nieuwe code even pasten. Hij accepteert nu ineens mijn command timeout van 2000 :-) Kortom, mijn VB hangt :-)

en als je hem debugt? stopt die dan bij Set RS = Conn.Execute(Query) of waar precies?

[whoami]

Kijk eens of je die query niet kunt optimalizeren, bekijk het execution plan van die query eens, etc....

Die query is gewoon niet efficient. Je hebt tig subqueries, en als je een datum veld vergelijkt met een varchar veld, dan zal dat veld ws eerst gecast worden (vraagt tijd), en zullen er ws ook geen indexen kunnen gebruikt worden.

[Verwijderd]

Ja, hij stopt bij het uitvoeren van de query, dan wacht ie op de SQL server, maar die vindt dat ie daar geen tijd aan hoeft te besteden blijkbaar

En nu wacht ie dus 2000 seconden

Ik ben het met jullie eens dat die Query brak is, zelfs zo brak dat ik meerdere keren de zelfde subquery uit voer.

ECHTER, dat neemt niet weg, dat in de SQL Query analyzer binnen 10 seconden een antwoord op mijn scherm staat, en via ADO er ineens een timeout optreedt. (zoals ik nu ook merk: egaal hoe hoog je 'm in stelt).

[ Voor 48% gewijzigd door Verwijderd op 24-05-2005 16:36 ]

[Verwijderd]

henkleerssen schreef op dinsdag 24 mei 2005 @ 16:34:
[...]

en als je hem debugt? stopt die dan bij Set RS = Conn.Execute(Query) of waar precies?

Die CASE WHEN, kan dat niet beter een IIF zijn?

Verder, wanneer je timestamps opslaat in varchars, kan je dan wel fatsoenlijke vergelijkingen maken?!

[edit]
Geeft de query analyzer alle records terug of alleen de top 10?

[ Voor 28% gewijzigd door Verwijderd op 24-05-2005 16:39 ]

[Verwijderd]

De Query Analyzer geeft ALLE records terug.
En voor alle mensen die aan de tijdsvelden twijfelen -> de resultaten in Query manager zijn correct.
Ook de resultaten in VB zijn -als ie loopt- juist. Dus ja, die varchar velden werken.
Bovendien, zo heeft Exact het bepaald, dus daar kan ik niks aan veranderen.

De huidige code is (even uit de verschillende functions/subs gehaald) :

Public Conn As New ADODB.Connection
Conn.Provider = "sqloledb"
Conn.Open "uid=sa;pwd=<PWD>;server=enlightment;driver={SQL Server};database=Globe202;"
Query = <lange query zoals hierboven>
set RS = Conn.Execute(query)

[ Voor 16% gewijzigd door Verwijderd op 24-05-2005 16:53 ]

[whoami]

Verwijderd schreef op dinsdag 24 mei 2005 @ 16:52:

En voor alle mensen die aan de tijdsvelden twijfelen -> de resultaten in Query manager zijn correct.
Ook de resultaten in VB zijn -als ie loopt- juist. Dus ja, die varchar velden werken.

Neemt niet weg dat het wel op de performance zal wegen.

De huidige code is (even uit de verschillende functions/subs gehaald) :

Plaats je code eens tussen [code ] tags aub. Dat maakt het geheel wat leesbaarder.

[edeboeck]

Heb je het geheel al eens getest met de SQL Profiler? Kwestie van te weten wat nu werkelijk gebeurt op DB-niveau als je de query laat lopen in je VB-code

[Verwijderd]

[quote]Verwijderd schreef op dinsdag 24 mei 2005 @ 16:52:
De Query Analyzer geeft ALLE records terug.
En voor alle mensen die aan de tijdsvelden twijfelen -> de resultaten in Query manager zijn correct.
Ook de resultaten in VB zijn -als ie loopt- juist. Dus ja, die varchar velden werken.
Bovendien, zo heeft Exact het bepaald, dus daar kan ik niks aan veranderen.

De huidige code is (even uit de verschillende functions/subs gehaald) :

code:

Public Conn As New ADODB.Connection
Conn.Provider = "sqloledb"
Conn.Open "uid=sa;pwd=<PWD>;server=enlightment;driver={SQL Server};database=Globe202;"
Query = <lange query zoals hierboven>
set RS = Conn.Execute(query)

[Verwijderd]

edeboeck schreef op dinsdag 24 mei 2005 @ 17:00:
Heb je het geheel al eens getest met de SQL Profiler? Kwestie van te weten wat nu werkelijk gebeurt op DB-niveau als je de query laat lopen in je VB-code

Graag....alleen nou komen er verschillende problemen.
1) Ik heb nog nooit iets zinnigs uit de SQL profiler kunnen halen
2) Waarschijnlijk omdat ik niet weet hoe ie werkt (lach me maar uit )
3) De informatie sneller voorbij komt geschoten dan je kunt lezen (en dan doel ik niet op het terug lezen, maar op die 75 andere gebruikers die ook queries uitvoeren).

[whoami]

Verwijderd schreef op dinsdag 24 mei 2005 @ 17:05:
[...]


3) De informatie sneller voorbij komt geschoten dan je kunt lezen (en dan doel ik niet op het terug lezen, maar op die 75 andere gebruikers die ook queries uitvoeren).

Je kunt ook filters op je trace zetten.

Maar, ik zou ook eens het execution plan bekijken in Query Analyzer van die query.

[Verwijderd]

Zal ik morgen doen. thnx zover!