Discussion on compiling and debugging of ASP program: for Beginners

Program | beginners

Many friends think ASP is not very studious, I think actually have a certain programming foundation, plus a little bit of skill, getting started is not difficult (but to do well is not very easy, a lot of relevant knowledge-what SQL Server database language, data structure ( These are in the optimization of the ASP algorithm to be familiar with.

In this only to talk about how I personally write and debug ASP, I hope to give a little help ...

　　Writing for ASP scripts:

First, note the distinction between HTML syntax and VBScript syntax. Because the ASP is mixed with HTML syntax and VBScript syntax (of course, I'm all written in VBScript syntax, but that kind of program is hard to read). It's best to use some editing tools that can mark HTML tags and vbscript tags, such as Ultra Edit.

I learned that the Editor's toolbar menu doesn't have to be too much, there is a general function on the line, because a lot of tools menu, editing area will certainly become smaller, this is what we do not want to see (you do not want to find an if the end of the end of the sentence to turn over the end If.) This is probably the reason I used to write ASP scripts in the past--hehe, the editing area of Notepad is bigger ...

Second, the writing process using indentation

Using indentation when writing a program can reduce a lot of unnecessary syntax errors. To avoid the implementation of your ASP program when prompted "missing end" what what ...

Usually refers to the use of indentation writing refers to the use of the convection control statement indentation, if I do not say, you should also know what flow control statements:

If ... Else ... End If
For ..... Next
Doing while ... Loop
Select case ... Case ... Case Else ... End Select
For each element in group ... Next

Wait a minute......

For example, write the following to check the error is more convenient:

If condition Then
Statement
Do While condition
Statement
Loop
Else
Statement
End If

Third, familiar with some of the ellipsis, such as:

If condition Then
Statement
End If
can be abbreviated as if condition then statement
Note: Else and end if can not be written back.
Wait a minute......

Try to familiarize yourself with the scripting language you want to use.

Spare some of the most common tutorials (such as VBScript language Reference or something) for future use.

Be very careful in spelling.


　　Debugging of ASP Scripts:

First, when you edit the implementation of a certain function of the ASP script, there must be a clear idea, as long as is: to achieve what function, the key to achieve what, how to control the flow of statements, etc. ... Although small items (such as a simple message system) are not necessarily to be written out, but at least have to know.

If you want to use the database, you must first design the database structure according to your project function

Third, do not wait until the entire ASP script all finished writing to start debugging. Are generally side of the writing side debugging (if you see I do is open two windows: An editor, an IE, edit the script, and then to the IE window refresh).

If your script has as many as hundreds of lines, even if you just input a correct script into the file, there's no mistake. And this long script file is hard to debug, and once you have an error, it's hard to find out exactly what went wrong-even if it was a grammatical error.

When debugging grammatical errors, we often use the "short cut" method to do it.

For example, the error hint is "line No. 236 error, missing end", so long code, it is difficult to know what is missing is that if or is a select ...

For example, the following procedure:

A whole bunch of statements
If

Else
(There's a whole bunch of statements here.)
End If

My usual practice is to truncate the section in parentheses and then try to run it and then gradually put the truncated part back (which is especially useful for debugging other people's edited scripts).

V. Marking and Debugging methods

Sometimes in order to know where the program has been executed, it is usually possible to add tags to the program, such as Response.Write "ABC", and then move the sentence, so that the program does not execute to where I want to go.

When debugging loops, it is often necessary to output the value of the loop control variable to the browser to help Debug.

Some errors caused by the value of a variable, such as a database connection or a recordset open error, typically output an SQL statement before an error statement to confirm that there are no errors in the SQL statement. For this reason, I usually use sql= "statement"/set rs=execute (SQL) instead of running set Rs=execute directly ("statement"), because when my statement goes wrong, I can easily get a response.write in front of it. SQL to see if there is a problem with the SQL statement.

Six, in the debugging form, for password table items, usually first turn it into text, and so on after debugging is changed to password.

Vii. Monitoring Variable method

When debugging some of the more variable scripts, such as chat room debugging, due to the large number of use to application and session variables, usually do some auxiliary script to see Application and session variables, so much more convenient.

Viii. taking fewer generations of multiple laws

debugging logical errors in Global.asa files is cumbersome, especially session.onend and Application.onend events.

Applicatoin.onstart event debugging is not difficult--because when you first open the browser, if the Global.asa file has syntax errors, the browser will prompt you where the error. But unfortunately, Session.onend can not see the hint. To make sure that your session.onend is not performing, you usually set a tag variable in Application.onstart, and then change the variable to a value in the Session.ond event, so that you can wait for the session timeout to see if the tag variable has changed, Change will prove that your session.onend is not executed.

For Application.onend debugging, you can take that part of the code to an ASP file, give it a certain condition (for example, what variable it uses, and then meet its conditions to see if there is a preset effect.) But usually application.onend are not too complex (complicated debugging pass).

Nine, as far as possible to some database connection string all parameters, lest cause unnecessary trouble.

Although some parameters are not required, it is better to give it all. I've tried it. A bizarre problem caused by not having enough parameters to connect to an Access database: Once the connection file has been modified, the correct result can be refreshed once, then it is not possible to refresh once, and even the "error cannot be pointed out."

Do not rush to error handling on_orror. Because the error itself can help us debug the script, once you have blocked the error, it is easy to not know what went wrong.

One of the best ways to reduce logic errors is to have a clear idea that it is difficult for others to help you.

So if you ask a logical error on the BBS, the answer first is: "What's Your source code?" "So unless you are for irrigation, it makes no sense to ask a question like this" Why my Recordset is empty "on the BBS.