ASP / VBScript Function Errors

I am developing an application in ASP and have moved all my SQL statements into functions.  This is to allow me to log activity and create an audit trail.

Now whenever the SQL throws an error it references the line of the function that executes the SQL.  However, it is (almost) always the variables that have been sent to the function that have caused the error.  Unfortunately I don't always know where the function was called from.  Some pages reference update or insert function multiple times for different data.

I am therefore wasting a lot of time working out where the error originated from.  Is there any way to establish where the function was called from.  I could then use this to write it to the screen when there is an error.
LVL 11
John EastonDirectorAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

plummetConnect With a Mentor Commented:
You could add error trapping inside the function and also pass a reference to the calling procedure, so an on error goto statement would  write out the error code plus the calling proc reference. It would however mean changing all your new functions and all calls to them. Nothing comes free though!

If you want an example let me know.

John EastonDirectorAuthor Commented:
This appears (if I understand it correctly) be related to SQL stored procedures which I am not using.  The functions are in in the ASP code.  Basically now if I get an error it will look something like this:

error '80040e14'
/assets/inc_sys.asp, line 16

This is the line of the function (which is located in an include file).  Prior to using the function the error might have been:

error '80040e14'
finance.asp, line 354

Now this is the line that is actually calling the function now and sending the wrong data to the function.  I need to get the second page and line information to troubleshoot the error - not the first one which is what the web server returns.
The new generation of project management tools

With’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Scott Fell, EE MVEDeveloperCommented:
A temporary way you can debug what is happening is adding a bunch of response.writes in the main code and use some sequential order so you can track what is going on and where things are breaking.  

' main page
response.write "*** STEP 1 ****"

 <!--#include file="MyFunctions.asp"-->

response.write "*** STEP 2 ****"

' Code calling function 1
response.write "*** STEP 3 ****"

' Code calling  function 2

response.write "*** STEP 4 ****"

' Code calling function 3

response.write "*** STEP 5 ****"

John EastonDirectorAuthor Commented:
That's essentially what I'm doing at present, but not so useful once the system is deployed.  Given I currently have over 700 database calls over nearly 100 pages (and growing) I was looking for a more advanced solution if one exists.
Scott Fell, EE MVEDeveloperCommented:
Sure, you can switch that out for silently recording errors to a text file or your database with something like
Set ObjMyFile = CreateObject("Scripting.FileSystemObject")
On Error Resume Next
LogFileName = "aspprotect.log"
LogFileDirectory = "c:\somedirectory"
'Open Text File.. If doesn't exist create it and append to it .. If exists just append to it
Set WriteMyData = ObjMyFile.OpenTextFile(LogFileDirectory & "\" & LogFileName,8,True)
RowHeaderString = Session("User_ID") & vbTab
RowHeaderString = RowHeaderString & Session("Username") & vbTab
RowHeaderString = RowHeaderString & NOW & vbTab
RowHeaderString = RowHeaderString & Request.ServerVariables("REMOTE_ADDR")
On Error GoTo 0
you could attach a debugger and view the call stack...
can't say i've ever done it with classic asp tho... this article reckons you can:
John EastonDirectorAuthor Commented:
@basicinstinct:  It looks like this is only for .NET, although the article does refer to ASP.  I guess this is bad authoring of the article.

@padas: I assume this would then just log the error message I current get, i.e. the function location not the calling page.  I don't mind the application aborting when it comes across an error - but I need to know the source of the error, not the location of the SQL Execute statement.

 @plummet: I thought about that too.  But after just replacing all my SQL statements with function calls the thought does not appeal.  

I'm surprised that within a function you cannot query the source - a bit like the window.parent function in JavaScript.
more like "arguments.callee" in javascript... don't think such a thing exists in vbscript
I quite understand! It's the way I'd go though. No pain, no gain etc.
All Courses

From novice to tech pro — start learning today.