[asp] on error resume next <-> if is null

[lexited]

ik heb een webpagina in elkaar gezet die nogal wat queries uitvoert.
het aantal queries dat door deze pagina wordt uitgevoerd op de database is +/- 600 waarvan 300 kruistable queries zijn, en de andere normale select's.

Verschillende velden worden opgeteld en dat zijn er ook nogal wat.

dit heb ik in korte tijd moeten maken, om mezelf wat tijdswinst te geven heb ik bij de berekeningen, ipv een nette 'if isnull' gebruikt gemaakt van 'on error resume next', waarmee hij ook over de null-waardes heen loopt.

ik sluit verder alle recordsets netjes

het werkt prima als ik het test. de executie tijd is wel redelijk lang, maar hij doet het prima.

maar soms begint de dllhost geheugen en processor tijd te eten, wat ik alleen op kan lossen door een reboot van IIS.

- ligt dit aan het totaal aantal queries, en de executie tijd?(+/- 40 sec.)
- is 'on error resume next' de oorzaak van dit fenomeen?

[gorgi_19]

Enig idee wat On Error Resume Next precies inhoudt en wat dit voor consequenties voor je code heeft?

Doet me een beetje denken aan het voorbeeld wat alarmnummer een tijd geleden aanhaalt:

quote: http://gathering.tweakers...message/17395910#17395910

code:

try 
    freemem(p)
except 
end;

Wat je niet ziet, dat bestaat niet

En dit lijkt me ook hier van toepassing....
Sowieso.. Kruistabel queries; toevallig MS Access gebruikt? Zo ja, dan vind ik 600 queries op een webpagina voor Access gewoon pure mishandeling van deze database.

[ Voor 122% gewijzigd door gorgi_19 op 13-08-2003 10:44 ]

[Jaspertje]

Lezen Jasper Lezen

[ Voor 79% gewijzigd door Jaspertje op 13-08-2003 10:41 ]

[CrashOne]

Volgens mij niet. En waarom heb je zo belachelijk veel queries nodig? Wat voor applicatie maak je?

[Disciplus-Simplex]

Om dat te weten te komen moet je (zeker in ASP oldschool) alles een voor een uit of aan zetten en Response.Write is vaak ook je beste vriend.
Verder is het verstandiger om zoveel queries in stored procedures op te nemen, mits je met een DB werkt die dat aankan. MS-Access dus niet. Met zoveel queries krijg je erg veel verkeer van DB naar ASP en is enorm inefficient EN is ook niet de bedoeling eigenlijk.

[CrashOne]

Ik kan me zo snel ook niks bedenken waarbij ik 600 queries nodig heb om 1 output te krijgen.

Heb je je DB wel efficient en logisch op gezet?

[lexited]

ik heb zo belachelijk veel queries nodig omdat het een totaal overzicht is. informatie uit een aantal tabellen moet per regel opgeteld worden.

(veld 1 = recordset1_veld1+recordset2_veld3
veld 2 = recordset1_veld2+recordset2_veld2 - recordset1_veld5
veld 3 = recordset3_veld2 * recordset4_veld1 + recordset1_veld2

en dit dus 25 velden lang, en onderaan de pagina staat de totaal telling van deze regels, 150 in totaal

het klopt dat het een acces database is. (wederom tijd tekort...)

ik heb ook al gegoogled op 'on errort resume next' , maar kon niet een duidelijke invulling geven anders dan dat hij op deze manier over fouten heen stapt.

[ Voor 29% gewijzigd door lexited op 13-08-2003 11:09 ]

[curry684]

dit heb ik in korte tijd moeten maken, om mezelf wat tijdswinst te geven heb ik bij de berekeningen, ipv een nette 'if isnull' gebruikt gemaakt van 'on error resume next', waarmee hij ook over de null-waardes heen loopt.

Stap 1 van dit probleem te debuggen lijkt me toch om deze actie ongedaan te maken

[CrashOne]

Ik zelf zou nooit on error resume nezt gebreuken omdat het je executie tijd van je script en de belasting van je server niet ten goede komt. Je kunt je fouten beter handmatig zelf scripten (dus wel je isNull, isEmpty etc gebruiken)

[gorgi_19]

lexited schreef op 13 August 2003 @ 11:02:
ik heb zo belachelijk veel queries nodig omdat het een totaal overzicht is. informatie uit een aantal tabellen moet per regel opgeteld worden.

(veld 1 = recordset1_veld1+recordset2_veld3
veld 2 = recordset1_veld2+recordset2_veld2 - recordset1_veld5
veld 3 = recordset3_veld2 * recordset4_veld1 + recordset1_veld2

en dit dus 25 velden lang, en onderaan de pagina staat de totaal telling van deze regels, 150 in totaal

het klopt dat het een acces database is. (wederom tijd tekort...)

ik heb ook al gegoogled op 'on errort resume next' , maar kon niet een duidelijke invulling geven anders dan dat hij op deze manier over fouten heen stapt.

On Error Resume Next vind ik een van de meest ranzige contructies ooit uitgevonden en hij wordt, zeker door ASP'ers, ontzettend fout toegepast.

Oftewel: Hierin zeg je: Negeer de fouten en ga verder naar het volgende. Inderdaad kan je zo oneindige loops krijgen.

Verder schieten mij dingen als aggregated function en 'apart' datamodel te binnen, maar dit zijn slechts vermoedens van mijn kant om zo het aantal queries te bedenken.

Wel moet je goed beseffen dat je niet verbaasd met zijn als je database opeens corrupt raakt met deze belasting.

Oftewel: coden met option explicit en zeer sporadisch met on error resume next (totdat je weet hoe je het goed moet gebruiken) zou een hoop fouten moeten voorkomen.

Sowieso kan je eens kijken in de debuggingfaq, hoewel ik er net achter kom dat de maker van de FAQ hier en daar nog een slordigheidje heeft laten staan..

[ Voor 9% gewijzigd door gorgi_19 op 13-08-2003 11:16 ]

[lexited]

curry684 schreef op 13 August 2003 @ 11:05:
[...]

Stap 1 van dit probleem te debuggen lijkt me toch om deze actie ongedaan te maken

ok.. ik kan me daar best in vinden, als dat de oorzaak van het probleem is.
daarom probeer ik ook uit te zoeken waar de schoen wringt.

[whoami]

lexited schreef op 13 augustus 2003 @ 11:02:
ik heb zo belachelijk veel queries nodig omdat het een totaal overzicht is. informatie uit een aantal tabellen moet per regel opgeteld worden.

(veld 1 = recordset1_veld1+recordset2_veld3
veld 2 = recordset1_veld2+recordset2_veld2 - recordset1_veld5
veld 3 = recordset3_veld2 * recordset4_veld1 + recordset1_veld2

Dat kan je ook prima in SQL oplossen.

code:

SELECT tabel1.veld + tabel1.veld2 ....

bv.

Daarnaast heb je nog functies zoals SUM, group by, etc.... Misschien moet je maar eens kijken of je datamodel wel deugd.

Als die berekende values niet veel veranderen in de loop der tijd, of je hebt echt veel of zware queries nodig om die waarden te berekenen, dan kan je ook nog altijd overwegen om een veld bij te maken die die waarde bijhoudt.
Zo kan je met een eenvoudige select die waarde verkrijgen.

het klopt dat het een acces database is. (wederom tijd tekort...)

Dat is toch geen excuus?
De keuze van de technologieën die je gebruikt zijn meestal van cruciaal belang, en dat geld ook voor een goed ontwerp van je datamodel.
Deze dingen nemen in het begin van het project misschien wel wat extra tijd in beslag, maar de tijd die je kan uitsparen later in het project (als je van de goeie technologieën en goede architecturen gebruik maakt) is ontelbaar.
Als je later deze dingen opnieuw gaat moeten aanpassen, is de tijdwinst die je hebt behaald door er niet of te weinig over na te denken, volledig in rook opgegaan.

ik heb ook al gegoogled op 'on errort resume next' , maar kon niet een duidelijke invulling geven anders dan dat hij op deze manier over fouten heen stapt.

on Error Resume Next is evil en zou je nooit mogen gebruiken.
Dat is het enige dat je erover hoeft te weten.

[ Voor 4% gewijzigd door whoami op 13-08-2003 11:17 ]

[lexited]

code met option explicit is een goeie gewoonte die ik hanteer
ik weet ook dat als ik de regel on error resume next weghaal en alle null waardes af vang, de code een stuk netter is.
ik wil alleen graag bevestiging dat dit de oorzaak kan zijn.

[gorgi_19]

lexited schreef op 13 August 2003 @ 11:18:
ik wil alleen graag bevestiging dat dit de oorzaak kan zijn.

Dat is niet te zeggen. Je hebt imho voor 95% een debugging probleem. On Error Resume next zorgt in de huidige vorm er voor dat je al niet kan debuggen.

[ Voor 27% gewijzigd door gorgi_19 op 13-08-2003 11:19 ]

[JohanDM]

Waarschijnlijk veroorzaakt de "On Error Resume Next" ergens een oneindige lus. Als je bevoorbeeld ergens zo'n code hebt staan:

ASP:

Set rs = con.Execute(strSql)
Do While Not rs.EOF
  'Do stuff
  rs.MoveNext
Loop

Als MS Access door de hoge belasting om een-of-andere reden een error geeft op lijn 1, zal ook lijn 2 een error geven omdat rs dan Nothing is, door de 'On Error Resume Next' zal hij dan verder gaan met lijn 3 en op lijn 5 gaat hij dan terug naar lijn 2 en de circel is rond: hoge processor belasting + stijgend geheugen gebruik.

Conclusie:

whoami schreef op 13 August 2003 @ 11:15:
[...]


on Error Resume Next is evil en zou je nooit mogen gebruiken.
Dat is het enige dat je erover hoeft te weten.