[asp VBScript] Execute geeft bij fout altijd line 0

[Verwijderd]

Voor een applicatie waarbij de code uit het geheugen komt ipv static file, gebruik ik het commando

code:

Execute(Application(etc))

ExecuteGlobal heeft trouwens dezelfde eigenschap.

Om de code uit te voeren. Dit werkt allemaal prachtig, tot op het moment dat er een scriptfout in de source staat. Dan geeft het Err objeect aan dat er een fout is gemaakt op regel 0. Op zich ook wel logische aangezien het geen fysieke codepagina betreft.

Maar met het oog op de dynamische foutopsporing niet echt handig, dat je niet in 1 oogopslag kan zien waar de fout precies zit. Je kunt dit probleem wel zo veel mogelijk minimaliseren door kleine code snippets te gebruiken, maar practisch is anders.

Heeft er iemand een idee of dit uberhaupt te veranderen is dmv een workaround, of zit er niets anders op dan gewoon erbij neer te leggen.

[mulder]

Daar komt ie: geen Execute gebruiken! Het is al vies, en vaak onnodig...

[Verwijderd]

Don Facundo schreef op vrijdag 22 april 2005 @ 15:12:
Daar komt ie: geen Execute gebruiken! Het is al vies, en vaak onnodig...

Geef maar een alternatief dan, waarmee je code kan uitvoeren die niet fysiek is opgeslagen.

[pjvandesande]

Verwijderd schreef op vrijdag 22 april 2005 @ 15:19:
[...]


Geef maar een alternatief dan, waarmee je code kan uitvoeren die niet fysiek is opgeslagen.

Waarom heb je de code niet fysiek opgeslagen?

[mulder]

Dat is compleet afhankelijk van wat je wilt doen?

[Verwijderd]

Don Facundo schreef op vrijdag 22 april 2005 @ 15:22:
Dat is compleet afhankelijk van wat je wilt doen?

Code vanuit een database wegschrijven naar Application object en vanuit daar uitvoeren.

Waarom?

Het is sneller, overzichtelijker, er zijn een hoop verschillende versies gekoppeld aan meerdere klanten binnen 1 applicatie -> maatwerk is dus beter mogelijk. Etc. etc.

[Creepy]

Het is sneller dan wat? Code in je DB is overzichtelijk? En maatwerk beter mogelijk dan wat?

Het zou mij beter lijken om je code UIT de DB te halen en op te splitsen in losse files. Net zo overzichtelijk, het laad sneller dan uit je DB en maatwerk is nog net zo goed mogelijk en het is nog beter te debuggen ook

[ Voor 57% gewijzigd door Creepy op 22-04-2005 15:31 ]

[mulder]

Het is sneller, overzichtelijker, er zijn een hoop verschillende versies gekoppeld aan meerdere klanten binnen 1 applicatie -> maatwerk is dus beter mogelijk. Etc. etc.

Code in database sneller en overzichterlijker? Nee. Wenselijk? Nee.

[Verwijderd]

Ben niet zo'n voorstanders van DLL's; ze zijn niet webbased te wijzigen, je moet ze compileren, je hebt er dus een redelijk duur programma voor nodig en ik betwijfel of ze daadwerkelijk sneller zijn dan code excuten vanuit een application object.

Het gaat er om dat er 1 applicatie is (webbased) die door veel klanten gebruikt moet worden. Aangezien dat betekend dat sommige functies moeten wijzigen en sommige niet, was er in de oude versie 1 (fysieke) asp pagina per functie. Vanwege de vindbaarheid werd de code gerangschikt per versie

Ongeveer zo dus

code:

Applicatie

        Versie A
            Functie 1A
            Functie 2A
        Versie B
            Funcite 1A
            Functie 2B

Zoals je ziet is er binnen versie B alleen functie 2 gewijzigd. Functie 1 is hetzelfde als in versie A. Op een gegeven moment moet functie 1 dus aangepast worden, en kun je dat in alle versie's gaan doorvoeren. Daarom hebben we besloten om de codebase in een database te plaatsen, waarbij de hyarchie veel overzichtelijker werd aangezien je er meer metadata aan kan koppelen dan bij een plain text file.