ASP-code checken op correctheid

[Stimpy001]

Is er een tool waarmee je je webpagina's met ASP-code kan checken op correctheid?

Hierbij gaat het dan met name om:
* Objecten worden niet naar nothing gezet. Dus niet goed uit geheugen opgeruimt.
* Connecties worden niet correct gesloten
* Recordsets worden niet correct gesloten

Dit alles heeft te maken met pagina's met een database verbinding en waardoor een webserver slechter gaat presteren.

[HenkS]

schrijf zelf iets, bedoel ff controlle door bestandje lopen dat je voor iederen OPEN ook een CLOSE hebt.

want volgens mij hebt je zoiets niet....

[Verwijderd]

D'r zijn zeker tooltjes hiervoor, ben er ooit langs gesurft, maar kan nu niks bedenken...

Kijk 's ff op www.componentsource.com, daar staan dermate veel componentjes/tooltjes dat dit er ook wel tussen moet staan...

[thijsc]

Visual Interdev van MS zelf heeft in ieder geval wel een uitgebreide debugger.

Misschien zit daar ook ergens een tooltje in dat dit kan?

[Verwijderd]

Op donderdag 10 januari 2002 16:51 schreef Stimpy001 het volgende:
Is er een tool waarmee je je webpagina's met ASP-code kan checken op correctheid?

Nee. Ik denk dat je doelt op een soort syntaxchecker/compiler voor VB/JScript? Het enige wat je hebt is 'option explicit', wat iets helpt.

Hierbij gaat het dan met name om:
* Objecten worden niet naar nothing gezet. Dus niet goed uit geheugen opgeruimt.
* Connecties worden niet correct gesloten
* Recordsets worden niet correct gesloten

De ASP runtime gooit alle objecten weg aan het eind van een webpage. Als er GEEN variables meer naar objecten wijzen, dan worden die objects automatisch opgeruimd uit je memory. ADO connecties en recordsets worden automatisch gesloten wanneer ze worden opgeruimd.

Dit gaat niet goed wanneer je ADO objects in het sessionobject stopt. Daarom moet je dat dan dus ook nooit doen.

Dit alles heeft te maken met pagina's met een database verbinding en waardoor een webserver slechter gaat presteren.

1) Kijk of je geen connection objects in de session/application objects stopt.
2) Gebruik waar mogelijk stored procedures, die je aanroept dmv ADO command objects
3) Gebruik connection pooling bij recordsets. Je hoeft niet eerst een connection te openen en die aan een recordset mee te geven als activeconnection. Je kunt ook de connectionstring meegeven als activeconnection en dan regelt ADO wel dat er een connection wordt aangemaakt, die uit de pool komt. Omdat je 1) niet doet, worden de connections weer in de pool teruggezet wat performance ten goede komt.